Midnight Mimosa Malware

Bitdefender's security researchers have identified a malware campaign (dubbed Midnight Mimosa) running on low-cost, multi-brand Android devices built on MediaTek platforms.

The malware ships preinstalled in the device firmware, and we found multiple system packages involved, depending on the device. It’s on the phone before the owner switches it on for the first time, and it can’t be uninstalled.

The malware runs with system-level privileges that allow it to silently install and remove apps, grant permissions, and load arbitrary code supplied remotely. This essentially means its operators could install and delete apps at will, tuning each device to their needs, including making them part of large botnets.

This scheme is likely designed mainly to generate revenue. The operators carry out ad and click fraud, collect device and installed-app information, and turn infected devices into residential-proxy relay nodes, making them zombies in botnets. This creates an additional revenue stream, as access to botnets for DDoS attacks is a hot commodity. The larger the botnet, the more money they can charge.

The system app itself doesn’t register the fraudulent impressions and clicks. The revenue engine is driven by the dropped cover apps, including real-looking weather, app-lock, note, and OCR apps, which load genuine ads through a legitimate ad SDK. The goal is simple: to load an invisible window on top of apps that registers ads being shown.

This system app - com.android.system.lite - was the first one identified, but it turned out to be the tip of the iceberg. As the investigation continued, we identified the same malware core shipping under a rotating set of system-sounding names, including com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot.

Each is a different build; some carry different signing certificates, and even different names. The package name is not the threat. The shared core underneath it is.

To top it off, we also discovered 13 apps currently present on Google Play that communicate with the same servers that control the malware. While these apps don’t have the rights that would allow them to be as malicious as the preinstalled packages, they are dangerous nonetheless.

The core of the infection chain is a platform-signed, persistent system application found pre-installed on affected Android devices.

The enabler silently deploys a rotating family of at least 32 unique disguised apps, including fake AppLock, weather, file-manager, icon-tool, OCR, and audio-editors.

It grants itself dangerous permissions such as Accessibility, Notification Access and SMS read/write - we noticed neither of these to be used in practice, but they're available to the operator on demand (arbitrary remote code loading). Our insights also show that Accessibility and Notification Access are automatically and repeatedly granted and ungranted after a short while.

The malware disables the Google Play Store app just before installing a payload app (probably attempting to avoid a potential Play Protect detection). After the payload runs, the Google Play Store app is re-enabled. There's also a safety net that re-enables the app when the user is present, to avoid triggering suspicions.

Payloads perform hidden ad fraud and automated click fraud or turn the device just another part of large botnets.

The system app and payload family use shared infrastructure, including a command-and-control service disguised as a weather API.

The enabler is not a single package. The same core ships under several system-sounding names across different builds and signing certificates.

The same ad-fraud code was also found in thirteen applications published on Google Play, under at least two developer accounts and thirteen separate signing certificates.

The investigation began with App Anomaly Detection, a technology in Bitdefender Mobile Security, which flagged com.android.system.lite: a package carrying the name and appearance of a core system component while behaving like nothing of the sort.

Most mobile security still runs on a single assumption: scan an app, and if it's deemed clean, it's safe. Bitdefender's App Anomaly Detection (introduced in 2023) exists because, in practice, the theory often doesn’t hold up.

Apps can sit dormant and turn hostile weeks later, sometimes only if certain conditions are met (targeted malware). Such apps can pass every static check, only to later pull their real payload from a server or cleverly unpack it from native code.

App Anomaly Detection closes this gap by watching what apps do, continuously, on the device itself - combining on-device machine learning, real-time behavioral analysis , and a range of other signals. It doesn't rely on whether an app looked clean yesterday; it reacts to the behavior itself, catching apps red-handed the moment they cross the line from benign to malicious.

That real-time behavioral analysis made all the difference. The application was preinstalled as a system app (platform-signed). It’s impossible to uninstall; there’s no store review, and it’s not the user’s choice. Every user-facing defense had already been bypassed by the time the phone was switched on. Behavior was the only thing left to catch it by.

From there, Bitdefender's insights showed what it had been doing. The system app was silently installing and removing a rotating set of payloads on the same devices, among them com.mobile.applock.wt, an app presenting itself as an App Lock tool, while missing the functionality its name suggested.

There’s no interface or code that would let it work as the name suggests, and it was completely hidden from the user. This was, in fact, a highly obfuscated Dropper malware in its own right - but it was not the root cause of the infection.

That is exactly how this investigation began. On paper, nothing com.android.system.lite invited a careful second look: a platform-signed component disguised as part of the operating system, with no icon and no visible behavior, its actual machinery buried in a native library that only came to life at runtime.

App Anomaly Detection flagged com.android.system.lite because while it posed as a core Android component, it didn’t behave like one. It repeatedly enabled sensitive access, including Accessibility and Notification Access, and silently installed and removed unrelated applications.

The supposedly system component was actually managing a rotating portfolio of hidden payloads, including fake AppLock apps used for ad fraud and for enrolling devices into a residential-proxy botnet.

The same source was installing a wider cluster of payloads, including com.mobile.applock.en, com.dmstudio.weather, com.dl.guard.lock, appicon.diy.tools.prop and picturetranslate.extractor.text.lite.

Our insights reveal these payload applications being installed and removed repeatedly on the same devices. This churn helps the operation reduce the length of time a payload remains visible in the app list, rotate hashes, and change the active monetization module, while the underlying system component stays in place.

Beyond generating revenue for operators, the devices can be turned into residential-proxy relay nodes, essentially becoming part of botnets and potentially helping launch DDoS attacks when called upon.

The payloads themselves are not new, and this method of shipping malware has been detailed in the past , but this specific campaign — the com.android.system.lite enabler found on devices with firmware signed using certificates attributed to Shenzhen Zediel , delivering malicious apps, some of which are similar to those from Dr.Web’s Android.Phantom operator’s family, now with residential proxyware added.

We can only confirm that certificates bearing the name Shenzhen Zediel were used to sign firmware on affected devices. However, how these certificates ended up on those phones — and whether the certificate owner was involved in or aware of the malware deployment — remains unclear. Furthermore, this is not the only company name that appeared in our investigation.

The malware ships with the device. What remains unclear is at which point in the supply chain it is integrated. It could be introduced by an ODM, a firmware integrator, a logistics partner, or another actor further down the distribution chain. The malware arrives in the ROM before the phone is sold, but identifying the specific party responsible for its inclusion requires information beyond the scope of this technical analysis.

And this is not the only way this malware gets onto people’s devices. There are countless other phones, as we’ll show in this research, that don’t have Zediel-signed firmware and still ship with the same malware.

The internet is flooded with extremely cheap, and sometimes straight-up counterfeit, Android phones. One way to make the money back on hardware sold that cheaply is to load it with software that earns afterwards.

Counterfeit flagship devices are offered on a mainstream marketplace. Model names of this kind, such as S24 Ultra, S25 Ultra, S26 Ultra, appear in our insights as the model strings reported by low-cost MediaTek hardware.

Since the core apps are very similar, we’ll detail only one of the malicious system apps we found and reveal how the ecosystem works.

The culprit, com.android.system.lite, is a pre-installed Android system application. It is not a normal app: and it ships signed for the platform, runs as the system user, and has the rights to install and remove packages and grant permissions to other apps without any user interaction.

These powers aren't implemented in its own APK code as they are hidden inside a native library (libeasy.so), which, at load time, RC4-decrypts and drops an obfuscated Java framework into the system-uid process.

That framework fetches a remote configuration from a C2 (command & control server), then downloads and loads stage-2 and stage-3 DEX plugins that carry the actual monetization payloads:

In-process ad fraud: fabricated ad impressions/clicks (the “wz” plugin).

Silent install/uninstall of partner apps as system-uid (“earn” / “gogo.third” plugins), with silent permission grants.

The partner apps it drops are themselves known droppers: a TCP proxyware/botnet (applock.en) and an ad-fraud+RCE dropper (applock.wt).

Insights confirm that one enabler silently installs a rotating portfolio of these partner apps onto real devices. The enabler is the on-device root of the whole scheme.

The system app (enabler)

The enabler app is a core, persistent, platform-signed system component that declares a set of privileged permissions. This is the foundation for everything that follows — only a platform-signed system-uid app can hold these permissions:

AndroidManifest.xml of the enabler (aapt2 dump). sharedUserId=android.uid.system + coreApp + persistent = firmware system component; the privileged permissions are what enable silent install/uninstall and silent permission granting.

The app label is the generic “System” and the icon is hidden. It’s invisible in the launcher and indistinguishable from a legitimate OS component. Its own APK dex (com.gogo.bb.sdk / Monitor* services) is only a thin host shell; the dangerous logic lives in the bundled native library.

Capability beyond what was observed

The manifest also requests access that has nothing to do with installing applications. Alongside the install and grant permissions, the enabler declares Accessibility Service, Notification Access, and SMS permissions. Even more interesting is that it enables the Accessibility and Notification Access services itself rather than prompting the owner to do so.

We didn’t see either used during the analysis. That’s worth noting, but it’s also worth not dismissing. An Accessibility Service can read the content of every screen, observe what is typed, and act on the interface on the owner's behalf. It is the standard mechanism behind Android banking trojans and remote-control fraud.

Notification Access allows reading any notification, including those from chat apps. SMS access allows one-time codes to be read and messages to be sent to premium numbers. These permissions are held by a component that cannot be uninstalled and already loads code from a remote server whose operator lineage includes premium-SMS subscription fraud.

The capability is present, self-enabled and remotely armable. What is done with it is a decision the operator makes at the C2, not a property of the samples we analyzed.

Native core libeasy.so drops a hidden framework

libeasy.so registers a single JNI method (nativeInit) whose real body is hidden behind a branch trampoline. At initialization, it caches Java crypto handles, then RC4-decrypts a 142 KB APK embedded in the library and writes it to disk. The dropped APK is the privileged framework.

libeasy.so load chain (IDA offsets; ET_DYN, imagebase 0 so file offset = vaddr). The family build tag 20240425 is assembled in nativeInit.

The dropped APK is cn.kw.lib.hex (215 classes), a string-obfuscated framework. Its strings are AES-128-CFB encrypted:

String cipher of the embedded framework. Same construction as the enabler’s own string cipher (key “dHhAZXhAc2Vy”) — a shared-code tie.

The two privileged primitives (grant + RCE)

The dropped framework implements the two advertised powers that are absent from the APK dex:

Grant any permission to any package:

Grant primitive (decoded strings of the embedded dex: “grantRuntimePermission pkg:”, “pm list package -3”). Fully parameterized by target ⇒ it can grant to any foreign package, not just itself.

Remote DEX/JAR update = remote code execution:

cn.kw.lib.dx.DxFactory via dalvik.system.DexClassLoader downloads/updates kwlib.jar (+ kwlib. ), md5-checked, version-gated (isNeedUdx, lst_udx_tim) endpoints come from remote config (getNavigation), not hardcoded.

RCE loader. Endpoints are supplied by the C2 config at runtime.

Stage-2 / stage-3 plugins and the on-device plugin store

The framework pulls a stage-2 host (kwlib.jar → cn.kw.lib.dx.DxFactory) which then loads three stage-3 plugins. Each plugin is cached under files/plg/ / as magic.o (a JAR disguised with a .o extension) plus a descriptor:

A plugin descriptor. The version + iconDesc values match exactly what the C2 returned in getConfigs — the plugin store is C2-provisioned.

The wz plugin renders ads where the owner has not asked for them. It uses two surfaces: full-screen activities, launched without the user having opened anything, and overlay windows drawn on top of whatever is already on screen. Rendering is triggered by screen-state changes, such as the display coming on, or by commands pushed across the ad mesh while the device sits idle.

The ad surface is also marked as secure, so it doesn’t appear in screenshots or screen recordings. That flag exists to protect sensitive content, such as banking screens, from being captured. Here it’s used in reverse: to make the fraudulent ad surface hard for the owner, or for anyone analyzing the device, to record.

The fraud itself is parameterized by a remote config whose Kotlin field names are cleartext:

The fraud ‘knobs’. silentPercent / notClickPercent are the probabilities of registering a click with no real tap; notClick*Rate bias is where on the creative the synthetic touch lands to look human.

Programmatic (synthetic) click — no user involved:

Random target + daily cap + interval throttle (paces the fake traffic to look organic):

Tap → silent deep-link launch of the app:

Time-based automatic ‘conversion’ report with a silent flag (60 s after show, no interaction):

The full fabrication path: render ad → performClick()/startActivity to fake clicks → auto-report ‘conversions’ after a 60 s timer with silent=true → throttle via silentPercent/notClickPercent/daily-cap. All events go to DotReporter → weatherlive.world/odborwer_dot/cm.

Fabricated clicks only earn money if an ad network attributes them to somebody, and attribution follows the ad SDK. The network credits an impression and a click to the application hosting its SDK and its ad unit identifiers. A hidden system component carrying no ad SDK would produce traffic that attributes to nothing and pays nobody.

That’s why the scheme needs the cover apps. The weather, app-lock, note and OCR applications the enabler installs are ordinary-looking apps carrying a legitimate ad SDK, and they are what the ad network sees. This is consistent with the wz plugin running inside the system process: the plugin supplies the logic, the timing and the synthetic interaction, while the ad unit, and therefore the payment, belongs to the cover app.

The two are bound peers in an ad mesh. Each cover app exports MyDataService under the action com.media.am.intent.action.BIND_SERVICE, a controller binds them and pushes ad payloads and commands across the mesh (initMediaApp, setAdData, transferData), and all of them report the same device identifier to the same weatherlive C2. One application can therefore drive impressions and clicks that another application renders and is paid for.

The division of labor across the scheme:

System enabler: silently installs and removes the partner apps, grants them permissions, and blinds Play Protect around each install. Hosts no ad units and is billed for nothing.

Native core and hidden framework: decrypt and load the privileged framework, and provide the permission-grant primitive and the remote code update channel.

Stage-2 and stage-3 plugins: C2-provisioned modules that run the fraud logic in process and perform the silent installs

Dropped cover apps: the revenue engine, and the only part of the scheme an ad network ever sees.

No-icon droppers: separate monetization tracks, proxyware and a second ad-fraud module.

C2: module control, fraud configuration, and collection of the fabricated events.

Silent install and permission laundering

The earn/gogo plugins silently install partner apps. The decision entrypoint and the install routine are the malware’s own code; it runs because the host holds INSTALL_PACKAGES as system-uid:

Silent-install path (com.earnsdk.lib.AppInstallHelper + earndex.h.c/f). Legacy installPackage(Uri,…) reflection is also present for older Android; on Android 13 the PackageInstaller session path is operative.

Because the host process holds INSTALL_PACKAGES as the system user, the createSession → openWrite → commit sequence completes with no PackageInstaller confirmation UI, and the enabler is recorded as the installing package. No user interaction is required at any point of the install.

Permission laundering: because the enabler installs the app, it can also silently grant it permissions a normal store app can never hold. The dropped weather cover app declares and actively uses WRITE_SECURE_SETTINGS — a signature (privileged) development permission:

The weather app's working WRITE_SECURE_SETTINGS write indicates it received a privileged grant it could never obtain from a normal install, which is consistent with the system-uid enabler granting it. The same package is also published on Google Play, in a build that holds no such grant. The privilege comes from how the application arrived on the device, not from the application itself.

Interaction with the system app: the dropped cover apps are bound peers in an ad mesh. They export MyDataService (action com.media.am.intent.action.BIND_SERVICE); a controller binds them and pushes ad commands (initMediaApp/setAdData/transferData) and they the same uuid and weatherlive C2.

Play Protect evasion (disable → install → re-enable)

Beyond suppressing the install prompt, the plugins blind Google Play Protect for the duration of the install. Using the host’s system-uid shell access, they run ‘pm disable com.android.vending’ (the Play Store, which hosts Play Protect’s on-device scanner) immediately before installing the partner APK, then ‘pm enable com.android.vending’ in both the success and failure install callbacks

The malicious install happens in a window where Google’s scanner is switched off. All three plugins implement it identically (obfuscated strings decrypt to the commands shown):

Play Protect evasion, confirmed across all three plugins (earn: earndex/e/a.java; gogo: bldex/e/a.java; wz: com/ads/cal/core/kt/ContextKtKt + GEMController). The obfuscated tokens decrypt to ‘pm disable ’, ‘pm enable ’ and ‘com.android.vending’. This is distinct from the silent install itself: the silent install removes the user prompt; disabling com.android.vending removes real-time detection.

Forged Play provenance – spoofed installer, absent frosting

Disabling the scanner conceals the install while it happens. A second technique conceals it afterwards, by rewriting where the app claims to have come from.

A privileged installer holding INSTALL_PACKAGES sets the recorded installer package itself, through PackageInstaller.SessionParams . The platform does not validate the value; it is whatever the installing process declares. On part of the corpus it is set to com.android.vending , so the device reports the app as sourced from Google Play.

The claim is falsifiable. Apps actually distributed through Google Play carry a Play-applied signature block called frosting , that is added server-side by Google as proof the APK passed through Play, and it cannot be produced off-platform. Where the installer field says com.android.vending but no frosting block is present, the provenance is fabricated rather than earned:

Samples recording Google Play as their install source while carrying no Play signature block. All three are enabler-family builds, not dropped payloads.

This inverts the usual triage shortcut. Suppressing the install prompt removes the user, disabling com.android.vending removes the automated scanner, spoofing the installer name removes the forensic trail that would show either happened. In this campaign, the installer field can’t be used on its own to attribute a sample or to clear one, frosting presence or absence is the reliable check.

Delivery model and field insights

The partner APK is not fetched separately at install time. It’s actually bundled inside the stage-3 plugin as assets/mediaapp-release.apk. The C2 controls which APK is delivered by controlling which plugin version it serves (getConfigs version → plugin pulled from CDN oss.showtimetool[.]com). The two partner APKs found bundled are byte-identical to known standalone dropper samples:

Field insights confirm the enabler is the installing package for the whole portfolio on real devices — both the no-icon droppers and the functional cover apps:

Packages recorded as installed by com.android.system.lite. Both the no-icon droppers and the functional cover apps are installed by the enabler; multiple distinct APK versions per package reflect C2 version rotation of the bundled payload.

The table above counts a single studied enabler's installed portfolio. Measured across the family as a whole, over a roughly two-year window, the campaign was observed on thousands of unique devices across more than 150 countries.

The geographic distribution is led by Mexico, France and Italy, followed by the United States, Germany, Brazil and Spain. Below the top, there’s a long tail across Africa, Southeast Asia and the Middle East.

The chart has two features of that spread that are worth highlighting. No single country is dominant, and the weight sits in two separate regional centers of gravity—Western Europe and the Americas—rather than one.

Neither is what a regional distribution channel looks like; a carrier or a national retailer produces one dominant market. Two centers with a long tail behind them is what hardware moving through international online marketplaces looks like.

We also have some details on the types of devices that carry this malware. Many devices are identified simply by the firmware they use and are likely cheap devices or clones of better-known ones.

As we mentioned earlier, Zediel-signed firmware is not the only way malware is shipped. The operators use many other devices, most of them likely visual clones of real phones, to embed the same malware.

Beyond the generic user agent strings, many of the affected models are counterfeit devices that borrow flagship names they have nothing to do with. Fake iPhones include: "i17 Pro Max", "i16_Pro_Max", or "17_Pro_Max", and an "iPadAirPro" for the tablet line.

Samsung's Galaxy is copied just as freely, with free-text "S25 Ultra", "S24 Ultra", or "Note 18 Ultra" strings that a genuine unit would never report; the campaign even spoofs the real codes, so "SM-S938B", a legitimate-looking user agent string for the Galaxy S25 Ultra, appears on devices that aren't Samsung.

Honor's Magic 15 MAX and a crop of no-name "Ultra" handsets round out the pattern. The same firmware ships under whatever prestige name sells a cheap phone, which is why the model column is a spoofing indicator, not a real device inventory.

The two highest-volume models, by contrast, are genuine, named brands: "S200 X" is associated with Doogee and "KINGKONG X" is associated with Cubot. These brand names also appeared in a publicly reported firmware-update incident documented on the XDA forum, which may indicate a broader pattern in certain segments of the supply chain.

The public report can be found on XDA forum in which owners traced a hidden com.android.sys.* package that reappeared under a new name after removal, the same self-updating behavior seen in this family.

Proxyware botnet (com.mobile.applock.en)

The partner app bundled in the earn plugin (com.mobile.applock.en, label “Locket”, a no-icon fake app-lock) is a single-purpose TCP back-connect proxy.

It enrolls the device as a remotely controlled relay node. It declares only INTERNET and ACCESS_NETWORK_STATE and contains no ads, no UI, and no dynamic code loading. The loader identifies itself as “EnLoaderLib” v1.0.6. Four code sites implement the full node lifecycle: enroll, command, tunnel, relay.

Enroll: each device registers with the C2 as a node:

Command channel: a raw TCP socket to the control host (not HTTP):

Command loop: the C2 pushes a list of targets and the device opens a tunnel to each and re-polls on a schedule:

Relay pump: bytes are piped verbatim between the C2 side and the target (the proxy exit):

Enroll → command → tunnel → relay (h/i, h/k, h/m, h/g). A central controller, enrolled nodes keyed by UUID/product id, remotely-supplied host:port targets, and a bidirectional byte relay: the victim’s connectivity is monetised as a residential-proxy exit node, and can reach arbitrary hosts including the local network.

Dynamic verification confirms the control infrastructure is live. On execution, the client resolves a control host via wildcard DNS and completes a TCP connection to it on port 6000, transmitting the registration record; the control host rotates across the four domains on successive attempts:

The control server 85.17.70.38:6000 (reached through the wildcard-DNS domains) is live and accepts node enrolment. A freshly-enrolled node received no relay targets in this observation; no traffic was relayed.

The second bundled partner ( com.mobile.applock.wt ) is the same no-icon fake app-lock shell with a different payload: an ad-fraud module (com.ctr.cbd) that reflectively loads remote DEX ad modules. The enabler therefore delivers both a proxyware and an ad-fraud dropper, selected by which plugin the C2 serves.

Two HTTPS channels to api.weatherlive.world, both AES-encrypted with HmacMD5-signed requests. The command channel (getConfigs) decrypts to a device-fingerprint request and a module-control response:

The getConfigs control channel dictates which plugins run, at which version, and where to fetch them (warningIcon URL, keyed by iconDesc md5). The telemetry beacon /odborwer_dot/cm returns only a fixed ack {"a":0}.

Module download URLs (from decrypted config; served as .png on the CDN):

wz (v20311) hxxps://oss[.]showtimetool[.]com/ssc/2026/08-13/[REDACTED].png

kwlib (v100007) hxxps://oss[.]showtimetool[.]com/ssc/2026/07-04/[REDACTED].png

gogo (v10014) hxxps://oss[.]showtimetool[.]com/ssc/2026/03-09/[REDACTED].png

earn (v5) hxxps://oss[.]showtimetool[.]com/ssc/2025/12-07/[REDACTED].png

A manifest-similarity query surfaced other fake-system applications. Because AOSP-disguised apps manifest structure, candidates were confirmed by hard family markers rather than manifest score: presence of the native core (libeasy.so, or a renamed variant), the RC4-dropped framework namespace cn.kw.lib, the C2 api.weatherlive.world, the Accessibility hook, and the distinctive versionCode 900000+ scheme.

The enabler is not a single package: the same core ships under several ‘system’ names.

Confirmed by binary analysis. The com.android.system.lite / com.android.sys.* cluster (versionCode 900000+, ‘system’/‘sys’ naming) is one enabler family sharing the libeasy / cn.kw.lib core and the weatherlive C2.

Why Shenzhen Zediel Co., Ltd.

The enabler com.android.system.lite is signed with platform-key cert 0105bc4c… (DN CN=ZED, O=ZED, L=ShenZhen, C=CN, [email protected] ). This maps to a real Shenzhen Android OEM/tablet maker, Shenzhen Zediel Co., Ltd. , which holds an IEEE MAC allocation:

MAC OUI A0:53:94 (MA-L block, registered 2021-11-03 ) → device-level IOC. Any device whose Wi‑Fi MAC starts with A0:53:94 is a Zediel build — usable to hunt all affected devices in telemetry regardless of installed payloads , and to estimate true fleet size.

The device models seen in telemetry corroborate this independently. The model strings reported by affected devices point overwhelmingly to low-cost, white-label handsets, in two distinct patterns.

The first is region-coded firmware strings, where the _EEA and _US suffixes are the regional build markers typical of no-name ODM devices, alongside raw board support package names. A board name surfacing as the product model is not something a user-installed app produces. It appears when the component ships inside the vendor firmware image.

The second is counterfeit flagship naming. Unbranded devices report themselves in imitation of Samsung flagships, alongside genuine budget rugged brands, two of which resolve to real vendors.

Model strings observed

Region-coded ODM firmware builds

J10_EEA, A9_EEA, T13_EEA, Q6_EEA

Board support package names

k62v1_64_bsp (MediaTek MT6762)

Counterfeit flagship naming

S25 Ultra, S24 Ultra, S26 Ultra

S200 X (Doogee), KINGKONG X (Cubot)

Representative device model strings from telemetry, grouped by pattern. Region coding and board names indicate firmware-level delivery; counterfeit flagship naming indicates the marketplace segment.

This list is best read as evidence of a distribution mechanism rather than a target list. Region-coded firmware strings and board-level build names indicate the payload resides in the ROM.

Counterfeit flagship names and budget rugged brands point to an ODM ecosystem sold globally through online marketplaces. The individual model names matter far less than what they collectively indicate— that this shipped in firmware.

Important clarification: The above analysis attributes the firmware/device supply chain based on the platform key that signs the enabler component. This technical attribution does not constitute proof that Shenzhen Zediel authored, distributed, or was aware of the malware. The payload operator (discussed below) is tracked as a separate actor, and multiple intermediaries may exist between the certificate holder and the final point of malware integration.

Malware operator lineage — Joker → Phantom/Click → this cluster

Dr.Web ’s Android.Phantom.5 entry lists our exact IOCs cgb.jingongbuxiao[.]com and 5.ahd187[.]com/thirdsdk/flowcashpack/ , and references zhuifengzhe[.]top , which is a domain used by Android.Joker.310.origin (2021) (premium-SMS subscription fraud + remote code loading). This ties a multi-year operator timeline:

Shared infrastructure

Android.Joker.310/242.origin

Premium-SMS fraud + remote DEX loading

Android.Phantom.5 (dropper) → Android.Click.429.origin

Byte-array-decrypt dropper → JS WebView click fraud

Cgb.jingongbuxiao[.]com ,

5.ahd187[.]com/thirdsdk/flowcashpack/ ,

Fyapi.freeflightbird[.]com ,

Newsadapi.zhuifengzhe[.]top

Preinstalled enabler + ad fraud + click fraud + residential proxyware

api.weatherlive.world ,

Cgb.jingongbuxiao[.]com ,

proxyware C2s (EnLoaderLib/dykr)

The same code on Google Play

The campaign is not confined to preinstalled firmware. Thirteen applications published on Google Play were found carrying the same family markers as the dropped cover apps, in builds distributed by Play itself.

com.audify.editor.wavrge

appicon.diy.tools.prop

com.audify.editor.pro

com.message.recovery.prorestore

picturetranslate.extractor.text.lite

com.notemaster.record.mark

com.arabmusic.tap.aghani_tamerhosny

Applications published on Google Play carrying ad-fraud family markers.

These are genuine Play builds. They carry the Play signature block whose absence identified the spoofed installs earlier in this report. The provenance is real, which means these applications passed Play review and were distributed by Google to users who went looking for a weather app or a QR scanner. No counterfeit hardware is involved.

The signing identities rotate deliberately. Thirteen packages carry 13 different signing certificates, spread across at least two developer accounts, fivedev and CPS Developer, with the remainder unresolved.

The link between them is the shared code, not the certificate. An actor who rotates signing identity per package is anticipating that any one of them will eventually be burned.

While they do provide functionality, they also load and display ads outside the app, sometimes even when the user isn't even using the phone.

This is an example of one of the applications listed in the Google Play Store that communicates with same servers and the embedded malware.

The campaign has two independent distribution channels. One rides in the firmware of cheap hardware and reaches users who never chose to install anything. The other goes through the official store and reaches users who chose deliberately. Both run the same ad-fraud code against the same infrastructure. Removing either channel leaves the other intact.

Preinstalled malware is a different threat class. Every user-facing defense assumes the owner is in the loop at installation: the install prompt, the store review, Play Protect, and the ability to uninstall afterwards.

A platform-signed system application holding INSTALL_PACKAGES and GRANT_RUNTIME_PERMISSIONS removes the owner from that loop entirely, and this campaign then switches off the one automated defender that remains. The compromise is complete before the phone is first switched on.

The layering is in itself a defense. The APK is an empty shell. The native library is a trampoline over an encrypted blob. The framework's strings are encrypted. The plugins are JARs carrying a .o extension, and the payloads are APKs served as .png files. The modules are provisioned from a remote server, so a sample examined statically often contains no active payload at all. Detection has to see through the packaging or watch the behavior.

One operator, many names. Rotating package names, signing certificates and renamed native libraries mean a package-name blocklist ages out immediately. Detection should key on the invariant core: libeasy.so and cn.kw.lib.hex, the api.weatherlive.world C2.

Remediation cannot rely on uninstall. Because the root component ships in the system partition, an affected owner cannot remove it by the normal route. Clearing the device requires firmware-level cleanup or disabling the component over ADB, and neither is realistic for most people who own these phones. The durable fix sits with the vendors and the marketplaces that ship and sell the affected firmware.

Indicators of compromise

api.weatherlive[.]world/br_upgrade/upgradeV2/getConfigs

AES/HmacMD5 module control channel

api.weatherlive[.]world/odborwer_dot/cm

Telemetry beacon (DotReporter)

oss.showtimetool[.]com

Module/asset CDN (payloads served as .png)

39.96.8.180:9008/ssc/rprt/bug

DX/S1 framework bug-report C2

120.78.215.151:80/api/bugLog

Embedded-framework crash C2

85.17.70.38:6000 (live)

EnLoaderLib proxyware C2 (applock.en); reached via the domains below

*.apple.{0aa0cf0637d66c0d[.]com, aa86a52a98162b7d[.]com, 442fe7151fb1e9b5[.]com, v46wd6uramzkmeeo[.]in}

Proxyware control hosts, pattern {productId}.apple. :6000

com.android.system.lite (vc 900000, “System”)

com.mobile.applock.en / .wt / .tg

Dropped gogo droppers (proxyware / ad-fraud)

libeasy.so (a8847b68428fde206b6dff8001051f92)

Native core; RC4-drops cn.kw.lib.hex

AES-128-CFB key=MD5(“aGV4QCFRQFcjRQ==”) IV 0102030405060708

hex framework strings

AES-128-CFB key=MD5(“dHhAZXhAc2Vy”)

AES/CFB key=MD5(“ZHhAIVFAVyNF”) (dx@!Q@W#E)

stage-3 plugin strings

installer name com.android.vending with no Play frosting signature

spoofed install source, forged Play provenance

Full sample set (120 MD5 hashes)

05ae89e761a890fa24f80f4be7263651

1da42505f1c83959c7f901f5139a158e

a147cd8f72aadfcf78f7723db6813e86

f456f0c6b89bd3d5124699d43971d094

2c77653b889dfccd649b82446f8c0d1b

com.android.deskclock

5d29e9b24708c3ec36d1d59036124838

com.android.deskclock

998e9010e5dfc4e4645f5572cbbe5b53

com.android.deskclock

b3a4405d1b8d43545d07b10581008d32

com.android.deskclock

0377ca97ac0ca35f9134052fede67a81

com.android.gallery3d

0b0d8e995e6ff24d4e9d00417446c25e

com.android.gallery3d

1414d4ef2d1191080abc59a407dcb6c5

com.android.gallery3d

345057421c7d9ac2b671c47449f35030

com.android.gallery3d

36deebfcda4012d18706cd170c1edf1f

com.android.gallery3d

37f18a20b9cf32e6f07450e903eaad7c

com.android.gallery3d

4507363415e7dc6d2cab14eeed137f6c

com.android.gallery3d

512a6db4a22244272826f39da020fb44

com.android.gallery3d

5b3a49938f455d1197736971c4c07228

com.android.gallery3d

6aca76699ec0bb8e51372d5c68c8359b

com.android.gallery3d

815b910f1efc95f38ba0c5b12c4f2129

com.android.gallery3d

c75ec7f3bcbc879aae9a21ad544d3232

com.android.gallery3d

d9fc6b2cd5eaa3929207f1029663d947

com.android.gallery3d

e51c11442a529dcd06dc7c8e45974ec2

com.android.gallery3d

e9b91e1d94bb3ff9a1c00b1c13eb7960

com.android.gallery3d

be22c91b4578ac2357a16133615df335

d5d88214170875386ab855172f881e51

com.android.sys.bcprot

dce5b0dc0e7d7059b5ab8384a7c24ec4

com.android.sys.bcprot

61aac6a98abd6dcff0dc41bb88159786

2b784622422f4280e0b3e38b30dd87bc

com.android.sys.gmsprot

2b7f1a7d5f5515c05d0c8e3857155ae2

3d3358b1057b1bfbd7e60577d8a31e0c

7400c34f7c6f866499029f5e759f58bd

d4ceb05682ecd60f4ebb4e76e02fcf7d

60bc23d3d453f258e2c4ca421cd086a9

com.android.system.lite

b862681953e945439167a736ba4cd41b

com.android.system.lite

ed1a6bed83899952b464c27aef9752cc

0903d7fd3e1d4a599a7eb3c5d356779b

a57a1ba15364dfb35d334f644d7049e8

cde0490e11db8ad54737c1df59ec658b

08d231c6a5303e543eb60d4181f6a4ea

com.mobile.applock.en

7f7747575980098bdc98e7b7aa362697

com.mobile.applock.en

d3faec4f013c4a1e84a1d681448312c0

com.mobile.applock.en

e75e183027bf897eda6447366c7acd01

com.mobile.applock.tg

20108557cacd24263e7e611afc327801

com.mobile.applock.wg

aac942aaf6ec0773cbac87fde4a6b284

com.mobile.applock.wg

cf20de9d9ddc952bb2265002d26a916f

com.mobile.applock.wg

f602230f54507cbddf5ef3014737d768

com.mobile.applock.wg

079298a7a506b376def4f4ff9a250672

com.mobile.applock.wt

20cefb2c667f945d482daded7e698eea

com.mobile.applock.wt

254bc5f6f81de1f3c47534e6febaf023

com.mobile.applock.wt

31b3280f1c0836c39c470932cf6c3e6f

com.mobile.applock.wt

3b35d3c5667136134b20a8411803c97d

com.mobile.applock.wt

3bc159537c909fa86bcc55eda127b5aa

com.mobile.applock.wt

42a9f64e75911c167ec7a163e8b24920

com.mobile.applock.wt

4a171f62d1bab01827b06ae73d4caafa

com.mobile.applock.wt

66c6512b9a73425aba40c8bfa95d23a0

com.mobile.applock.wt

6df909898f5f1394e78508d1152fab38

com.mobile.applock.wt

6ee2be3e5558085b532dacc8db61f3e9

com.mobile.applock.wt

6eea0568d5cc776ae03e09149cec3cd8

com.mobile.applock.wt

765d3ce85a6393d05973c4cfa7738116

com.mobile.applock.wt

90e0d27d808105167fdaa3a22b918217

com.mobile.applock.wt

9e7b34e63d8d38e37667f88a945ae69a

com.mobile.applock.wt

a02f28387527abe90d73d2879f671972

com.mobile.applock.wt

abe12db77a62ecb99d6ab5dc4fff18c7

com.mobile.applock.wt

de66cac88f156c3227749e03bdf7cf54

com.mobile.applock.wt

e6650dc6721aaa27f8a289ff92e613ff

com.mobile.applock.wt

e7c56b4f580da53cd0e4f11d1a11e402

com.mobile.applock.wt

2de346602433cdd1668f36b2e9db0be1

com.mobile.applock.xk1

af16072864ae0f9d755f8cf00fded359

appicon.diy.tools.prop

e974cf4cc5d55cddc04f026dd3ea72b8

appicon.diy.tools.prop

250205ee4b8de59e60c745856f439608

af7f1eef22bf5ee3d0a394f53ba7e1b8

com.arabmusic.tap.aghani_tamerhosny

7322d8a65a56a7ab09f4d526cb343e3d

0b8d3cd264c191f4884a25d0cc5318b5

33b2d3ec9a35cfb0b5a5d7b24ce4140e

3bb270d4927e2a8385793d9084a92fd3

4e46549122c0236307c5eef8891466f5

642d84ed5660407b972f1df642acb192

9a3d04aa36654b5c4b21edd22e46f92d

b7d0d5ae09b0d2d2f999c1087c450456

cdfcc848e16660d607aba6ecf24567f4

f0b7b1c940ebcee97eb68f528682fc50

1150da1af88729e54a34b8da5a2741c7

36f9e8cf47a28f9803fba427cf02a25c

6739fe083cfa8dec9b4f989ccba0e99e

ca7e2d265fc35aede432c4636a2cf4cb

fcb9f38cc687fc8a4637e0acdf91ab66

c55c9d7e12cc273b812ceffca8f62d4b

9a46098de785ae732e5fced55a2f3063

d145b14b9cc15799485f2592b2c16d9a

0a26a9d5f7ab91cb5eed852cf83ef078

294ab3f586d76772ae89add417cf6324

a13af0174bc211709e8b73bf60492a17

b974ef4106af6b932df352563a9b8b3c

e9ec6d7b50c1e54cd523283b9de55e10

5400ffac371c5e5c9b7f3705ce9faca5

com.message.recovery.prorestore

92f2fd8bcccc8ec4ffa64c7f6b3b9b8d

com.message.recovery.prorestore

ab8d6be686ca9413e27a11e85f9cef1a

com.message.recovery.prorestore

879168159c155758dbfd7a76e8f21548

com.notemaster.record.mark

b6c5f7dfaf9d47cd67380a48df5e1731

com.notemaster.record.mark

cb19dbf279a3488aec76c17e8e122c14

com.notemaster.record.mark

fc812444baa071f5141ddad812d673de

com.notemaster.record.mark

4f7d3c5859100d65ff02449884841b9c

50e9cdc3ed145bbc688356eda07f8eb3

9f1e2249003ab22cf8a38048e0ff6f6c

e39bddf592016ad6d0784770df3e2ffe

7469c9c06e5f324ca608e0140156bbad

4521a5bbe0f33a15da86bd80ff5d6d9c

picturetranslate.extractor.text.lite

8ec360829f4f7ae8dcae47c02b996762

picturetranslate.extractor.text.lite

d56158a2cc8d13778df850907733b2c4

picturetranslate.extractor.text.lite

fac6548a4a7a88156468b809c4f877f5

com.audify.editor.wavrge

ac8957a474f8aa812c7b233aafde4723

appicon.diy.tools.prop

cf4f24fdd283f80313565b08fea9d06d

com.audify.editor.pro

3c098465af131141996ff840bd34e791

387f7af167530486adcf3d8546063462

ee4e778e53ce4d4339d7c7888d06384d

c8ea2a7c1f52c4c2474475c28373ee27

836739fe7196437d8e998245b6f2b3b4

picturetranslate.extractor.text.lite

d6ba4044f9d57f7e86d83187982ed593

com.notemaster.record.mark

838dc8fcde1b28171e404ece1cfcde44

com.arabmusic.tap.aghani_tamerhosny

da67e37be01c20566990152ecfb14ed1

Legal Disclaimer: This article is published for informational and educational purposes only, as part of Bitdefender’s ongoing security research mission. The information presented is based on technical research conducted by Bitdefender Labs using proprietary detection technologies and publicly available sources. Bitdefender does not make any legal determination regarding the activities described herein and does not claim that any named entity has engaged in illegal conduct. The identification of certificates, package names, or infrastructure associated with particular companies or brands reflects technical observations only and does not constitute an allegation that such parties authored, distributed, or knowingly facilitated malware distribution. Readers should exercise their own judgment and consult appropriate authorities or legal counsel if they believe they have been affected by any of the activities described. Domain names, URLs, and technical indicators listed in this article are provided solely to help consumers and security professionals identify potentially harmful infrastructure. All trademarks mentioned belong to their respective owners. Bitdefender disclaims any liability for actions taken based on the information in this article.