SparkKitty：SparkCat的小兄弟——App Store与Google Play中发现的新型间谍木马

概述

2025年1月，我们发现SparkCat间谍软件活动，旨在窃取受害者加密钱包信息。该威胁行为者分发包含恶意SDK/框架的应用，等待用户打开特定屏幕（通常是支持聊天）后，请求访问设备相册，使用OCR模型选择并外泄感兴趣图像。虽然SparkCat能搜索图像中任何文本，但该活动专门针对包含加密钱包助记词的照片。恶意软件通过非官方渠道以及Google Play和App Store分发。现在，我们再次发现新型间谍软件已渗透官方应用商店，认为其与SparkCat相关，同样针对受害者加密货币资产。

关键事实

• 恶意软件针对iOS和Android设备，通过野生分发及App Store与Google Play传播（后者已移除应用）。
• iOS上，恶意负载作为框架（主要模仿AFNetworking.framework或Alamofire.framework）或混淆库（伪装为libswiftDarwin.dylib）交付，或直接嵌入应用本身。
• Android特洛伊木马有Java和Kotlin版本；Kotlin版本是恶意Xposed模块。
• 虽然大多数版本 indiscriminately 窃取所有图像，但我们发现相关恶意活动集群使用OCR选择特定图片。
• 该活动至少自2024年2月以来一直活跃。

从可疑网店开始

在例行监控可疑链接时，我们偶然发现几个相似页面分发Android版TikTok修改版。这些修改版本中，应用主活动会触发额外代码，代码然后从hxxps://moabc[.]vip/?dev=az请求Base64编码配置文件。解码后配置文件示例如下：

1
2
3
4
5
6
7
8
9

{
    "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"
    }
}

配置文件中的链接在应用中显示为按钮，点击后在WebView中打开名为TikToki Mall的在线商店，接受加密货币支付消费品。不幸的是，我们无法验证是否合法商店，因为用户需邀请码注册购买。

虽然应用中未发现其他可疑功能，但直觉促使我们深入调查。检查分发应用的网页代码时，发现一些有趣细节，表明它们可能也在推送iOS应用。

iOS应用交付方法

在iPhone上访问网站会触发一系列重定向，最终到达粗略模仿App Store的页面，提示用户下载应用。iOS不允许从第三方源下载运行任意应用，但Apple为Apple Developer Program成员提供所谓供应配置文件，允许开发证书安装在用户设备上。iOS然后使用此证书验证应用数字签名并确定是否可以启动。除证书外，供应配置文件包含其过期日期、授予应用的权限以及关于开发者和应用的其他信息。配置文件安装在设备上后，证书受信任，允许应用运行。

供应配置文件有几种类型。开发配置文件用于测试应用，只能分发给预定义设备集。App Store Connect配置文件允许发布应用到App Store。企业配置文件创建用于允许组织开发内部使用应用，安装到员工设备，无需发布到App Store且无安装设备限制。虽然Apple Developer Program需要付费会员和Apple开发者验证，但企业配置文件常被滥用。不仅用于不适合App Store的应用（在线赌场、破解、作弊或流行应用非法修改版）开发者，还用于恶意软件创建者。

恶意TikTok修改版中，攻击者使用企业配置文件，如其体中以下键所示：

1
2

<key>ProvisionsAllDevices</key>
<true/>

安装任何供应配置文件需要直接用户交互，流程如下： ![Profile installation flow]

寻找铜，发现金

与Android对应物一样，安装的iOS应用包含库，在用户配置文件窗口内嵌入可疑商店链接。点击这些在WebView中打开。看似简单案例：另一个流行应用修改版试图赚钱。但iOS版本中一个奇怪细节引起我们注意：每次启动时，应用请求访问用户相册——对原始TikTok高度不寻常行为。此外，包含商店的库无代码访问相册，Android版本从未请求图像权限。我们被迫深入检查应用其他依赖项，导致发现假装AFNetworking.framework的恶意模块。为 foreshadowing， spotlight 一个 curious 细节：某些应用称其为Alamofire.framework，但代码本身完全一样。AFNetworking原始版本是开源库，为开发者提供方便网络操作接口集。

恶意版本与原始版本不同，修改了AFImageDownloader类并添加了AFImageDownloaderTool类。有趣的是，作者未创建单独初始化函数或更改库导出符号以启动恶意负载，而是利用Objective-C特性，允许类定义特殊load选择器，应用加载时自动调用。此情况下，恶意负载入口点是+[AFImageDownloader load]选择器，原始框架中不存在。

恶意负载功能如下：

1. 检查应用主Info.plist配置文件中ccool键值是否匹配字符串77e1a4d360e17fdbc。如果不同，恶意负载不继续。
2. 从框架Info.plist文件检索ccc键Base64编码值。此值解码后使用AES-256 ECB模式解密，密钥p0^tWut=pswHL-x»:m?^.^)W填充空值达32字节长度。某些样本也观察到使用密钥J9^tMnt=ptfHL-x»:m!^.^)A。如果配置中无ccc键或键值为空，恶意软件尝试使用键com.tt.cf从UserDefaults检索加密字符串——应用可存储信息用于后续启动的数据库。
3. 解密值是URL列表，恶意软件从中获取额外负载，使用相同方法加密。此新密文包含用于外泄被盗照片的C2地址集。
4. 上传照片前最后一步是接收C2服务器授权。为此，恶意软件发送GET请求到/api/getImageStatus端点，传输应用详情和用户UUID。服务器响应以下JSON：

1

{"msg":"success","code":0,"status":"1"}

code字段告诉应用是否延迟后重复请求，0意思否，status字段指示是否有权限上传照片。 接下来，恶意软件请求访问用户相册。然后注册回调函数监控相册内任何更改。恶意软件外泄任何可访问未上传照片。为跟踪哪些照片被盗，创建本地数据库。如果相册在应用运行时修改，恶意软件尝试访问并上传新图像到C2服务器。

数据传输直接在选择器[AFImageDownloader receiptID:andPicID:]内执行，通过PUT请求到/api/putImages端点。除图像本身外，应用和设备信息以及唯一用户标识符也发送到服务器。

深入挖掘

当在修改版iOS版TikTok中发现间谍软件组件时，我们立即想知道特洛伊木马是否有Android对应物。初始搜索引导我们到一堆加密货币应用。这些应用入口点嵌入恶意代码，请求带有C2地址的配置文件，然后使用AES-256 ECB模式解密。这些解密地址然后被特洛伊木马用于发送GET请求到/api/anheartbeat。请求包括受感染应用信息。特洛伊木马期望JSON响应。如果code字段为0，意味着允许与该C2通信。JSON中status标志确定特洛伊木马是否可以发送受害者图像到服务器。

此恶意软件主要功能——从相册窃取图像——工作在两阶段。首先，恶意软件检查status标志。如果设置为允许文件上传，特洛伊木马然后检查外部存储上名为aray/cache/devices/.DEVICES的文件内容。第一次运行时，特洛伊木马写十六进制数到此文件。数字是包含受感染设备IMEI、MAC地址和随机UUID的字符串的MD5哈希。此文件内容然后与字符串B0B5C3215E6D比较。如果内容不同，特洛伊木马上传相册图像以及受感染设备信息到命令服务器，通过PUT请求到/api/putDataInfo。如果内容相同，只上传按字母顺序排序列表的倒数第三张图像。很可能攻击者使用此特定功能调试其恶意代码。

后来，我们发现此特洛伊木马其他版本嵌入赌场应用中。这些使用LSPosed框架加载，设计用于应用代码钩子。本质上，这些特洛伊木马版本充当恶意Xposed模块。它们钩住应用入口点并执行代码类似于我们之前描述的恶意软件，但有一些有趣变化：

• C2地址存储位于模块资源和恶意软件代码内。通常，这些是两个不同地址，都用于获取C2信息。
• 解密C2地址中，特洛伊木马选择对应最快服务器。通过顺序发送请求到每个服务器完成。如果请求成功，记录响应时间。最短时间然后确定使用哪个C2服务器。注意此算法本可无需存储中间值实现。
• 代码使用自定义名称用于类、方法和字段。
• 用Kotlin编写。我们发现的其他版本用Java编写。

官方应用商店中的间谍软件

包含恶意负载的Android Java应用之一是具有加密交换功能的 messaging 应用。此应用上传到Google Play并安装超过10,000次。研究时仍在商店中可用。我们通知Google，他们从商店移除应用。

我们发现另一个受感染Android应用名为币coin，通过非官方源分发。但也有iOS版本。我们在App Store上找到并提醒Apple其商店中存在受感染应用。

Android和iOS版本中，恶意负载是应用本身一部分，非第三方SDK或框架。iOS版本中，中央AppDelegate类管理应用生命周期，注册其选择器[AppDelegate requestSuccess:]作为处理程序用于返回到i.bicoin[.]com[.]cn的请求的响应。

在响应中，imgUrl字段包含关于发送照片权限的信息（1意思授予）。一旦特洛伊木马得到绿灯，使用类似于我们之前描述的方法：下载加密C2地址集并尝试发送图像到其中之一。默认，它会击中列表中第一个地址。如果那个宕机，恶意软件只是移动到下一个。照片发送功能在KYDeviceActionManager类内实现。

可疑libcrypto.dylib修改

调查期间，我们还偶然发现包含另一个可疑库的样本：OpenSSL加密原语库libcrypto.dylib的修改版本。它以名称如wc.dylib和libswiftDarwin.dylib出现，有使用LLVM混淆的初始化函数，并包含链接到我们之前在其它恶意框架中看到的配置。它还导入PHPhotoLibrary类，用于我们提到的文件中相册访问。有时库与恶意AFNetworking.framework/Alamofire.framework一起交付，有时不。

与此恶意软件其他变体不同，此特定库未实际联系嵌入其中的恶意配置文件链接。这意味着我们必须手动挖掘负责其与C2初始通信的代码。尽管这些库样本高度混淆，但一些如哈希c5be3ae482d25c6537e08c888a742832的样本，仍有交叉引用到代码部分，其中使用加密配置页面URL。此函数转换URL字符串为NSString对象。

使用Frida，我们可以执行任何代码片段作为函数，但简单转换字符串为NSString对象不足确认库的恶意意图。所以，我们跟随交叉引用向上几级。当我们尝试执行与URL工作的函数 during its execution时，发现它正做GET请求到恶意URL。然而，我们无法立即得到响应；URL指向的服务器已经 inactive。为使函数正确运行，我们使用Frida替换链接为工作之一，我们知道确切返回数据以及如何解密。通过设置日志钩子在objc_msgSend调用上并使用交换URL运行恶意函数，我们获得所需关于调用的信息。下面是我们用于此的Frida脚本：

 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();

我们的怀疑被确认：恶意函数确实加载并解密C2地址配置从给定URL。然后使用此C2发送设备数据，遵循我们之前描述的相同模式并使用相同AES-256密钥。下面是函数执行日志摘录。

函数执行日志上方清楚显示它使用来自加密配置文件的IP地址。设备数据发送到此IP的/api/getStatus端点带有来自之前样本的熟悉参数。我们还看到服务器响应包含我们之前遇到的code和status字段。所有这一切强烈表明此库也参与窃取用户照片。唯一我们尚未精确定位的是此恶意函数激活的确切条件。启动时，库联系C2，其地址加密 within it，发送设备信息并期望来自服务器的JSON字符串响应。研究时，我们未找到任何带有活动C2地址的样本，所以不知道它寻找的精确响应。然而，我们假设响应——或后续响应——应包含开始发送照片的权限。

另一个活动集群？

研究期间，我们偶然发现大量页面提供下载各种诈骗iOS应用以PWA（渐进式Web应用）格式。乍看，这些页面似乎与本文描述的活动无关。但它们的代码与分发恶意TikTok版本的页面惊人相似，促使我们调查用户如何登陆它们。挖掘流量源时，我们发现各种诈骗和庞氏骗局广告在流行平台上。

这些包含PWA的页面也包括部分提示用户下载移动应用。对于Android用户，链接下载APK文件，通过WebView打开诈骗平台。

除仅仅在WebView中打开诈骗网站外，这些下载的APK有另一个功能。应用请求读取存储权限。一旦授予，使用Loader API注册其内容下载事件处理程序。此处理程序然后选择所有JPEG和PNG图像。图像使用设计用于光学字符识别的Google ML Kit库处理。ML Kit搜索文本块然后分解为行。如果找到至少三行包含最小三字母单词，特洛伊木马会发送图像到攻击者服务器——其地址从Amazon AWS存储检索。

我们 moderately confident 此活动集群与上述相关。原因如下：

• 恶意应用也聚焦加密货币主题。
• 采用类似策略：C2地址也托管在云存储中，相册内容外泄。
• 分发iOS PWA的页面看起来类似于用于下载恶意TikTok修改版的页面。

鉴于两个活动集群间此连接，我们怀疑前面提到的应用创建者可能也通过社交媒体广告传播它们。

活动目标和目标

与SparkCat不同，我们上方分析的间谍软件未显示攻击者感兴趣受害者加密资产的直接迹象。然而，我们仍然相信他们窃取照片正是为此目标。以下细节引导我们这些结论：

• 加密专属商店嵌入TikTok应用内 alongside 间谍软件。
• 发现间谍软件的应用中，几个是加密主题。例如，App Store中币coin定位自己为加密信息跟踪器，SOEX messaging 应用也有各种加密相关功能。
• 分发间谍软件的主要源是 cookie-cutter 应用下载平台网络。调查期间，我们发现大量域名分发描述的特洛伊木马和PWA（渐进式Web应用）。用户从各种加密货币诈骗和庞氏骗局站点定向到这些PWA。

我们的数据表明攻击者主要针对东南亚和中国用户。我们发现的大多数受感染应用是各种中国赌博游戏、TikTok和成人游戏。所有这些应用最初专门针对上述区域用户。

此外，我们相信此恶意软件链接到SparkCat活动，这是我们推理：

• 一些感染SparkKitty的Android应用使用与感染SparkCat的应用相同框架构建。
• 两个活动中，我们发现相同的受感染Android应用。
• 恶意iOS框架内，我们发现调试符号。它们包括来自攻击者系统的文件路径，指向他们的项目正在构建的地方。这些路径匹配我们之前在SparkCat中观察到的。

要点

威胁行为者仍然积极危害官方应用商店，不仅Android——iOS也是目标。我们发现的间谍活动使用各种分发方法：通过感染恶意框架/SDK的应用从非官方源传播，以及通过恶意应用直接在App Store和Google Play上。虽然不技术上或概念上复杂，但此活动至少自2024年初以来一直进行，对用户构成重大威胁。与之前发现的SparkCat间谍软件不同，此恶意软件不挑剔从相册窃取哪些照片。虽然我们怀疑攻击者主要目标是找到加密钱包助记词截图，但其他敏感数据也可能存在于被盗图像中。

判断分发源，此间谍软件主要针对东南亚和中国用户。然而，它无任何技术限制会阻止它攻击其他区域用户。

我们的安全产品检测与此活动相关的恶意软件