ARTICLE · 1045064
威胁情报|FomoPeek App Store 投毒与 iOS 内核利用分析
近期，慢雾安全团队收到多起用户资产被盗反馈。经核实，相关事件均涉及私钥泄露，其中部分受影响用户曾下载并使用 FomoPeek 1.1–1.2 版本 App。
我们与 OKX 安全团队联合分析确认，FomoPeek 1.1 与 1.2 植入了 apptrace 和 libapptracecore 两个恶意模块，具备远程配置、内核漏洞利用、沙盒逃逸、Keychain 解密及跨应用数据采集能力。
动态验证显示，应用会从 Bitbucket 获取加密的 C2 地址，并向 api-a95f0ed200f.assisaint[.]com 上报设备信息、接收远程配置。测试期间，C2 返回的 exploit_enabled 为 false。为验证后续执行链路，我们在隔离环境中通过 Hook 将客户端解密后的相关开关修改为 true，随后获取到针对 19 个钱包及笔记应用的采集清单，并捕获到 Apple 备忘录容器被打包上传的完整请求。
通过 Hook 客户端加密函数，我们解密了该通道的请求与响应。服务端返回的配置证明攻击者可通过服务端远程开启漏洞利用、调整执行周期，并控制其定期重复运行。
我们基于从 App Store 官方渠道获取的历史版本 IPA 完成逆向分析与样本溯源。结果显示，1.0 未发现上述恶意模块；1.1（build 105）于 2026 年 9 月 9 日首次植入；1.2（build 110）于 9 月 12 日上线，并沿用同一套代码；1.3（build 111）于 9 月 17 日将两个 framework 整体移除。因此，明确受影响的 App 版本为 1.1 和 1.2，相关恶意模块通过 App Store 官方版本分发，并非第三方重签名或侧载产物。
该框架在代码层面声明的系统版本覆盖范围为 iOS 12.0–18.7.2 以及 iOS 26.0–26.1，说明其攻击目标并非仅限于低版本系统或老旧设备。
MistEye 响应
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。
MistEye 已第一时间通过情报推送与客户告警通道同步风险。
一、背景
1.1 从用户反馈到样本溯源
部分资产被盗用户在事件发生前曾安装并使用 FomoPeek。为核实其与私钥泄露事件之间的关联，我们从 App Store 官方渠道获取该应用的历史版本 IPA，并对包结构、加载依赖、签名归属及二进制内容进行了逐版本分析。
1.2 一款看起来完全正规的 App
从公开信息看，FomoPeek 具备一个正常项目应有的全部外观：
项目 | 公开信息 |
App 名称 | FomoPeek – Whale Tracker & Smart Alerts |
App Store ID | 6806199011 |
首次发布 | 2026-08-29 |
开发者显示名 | WhaleScanv |
Seller / 法律主体 | Porter Manufacturing, L.L.C. |
官网 | fomopeek[.]com |
官方 X | @FomoPeek |
定位 | Solana / Ethereum / TRON 钱包监控、Whale Tracking、链上提醒 |
系统要求 | iOS 16.0+ |
价格 / 分类 | 免费 / 财务 |
当前版本 | 1.3（2026-09-18 更新） |
该 App 在 App Store 正常上架，有官网与官方社交账号，对外定位是“只读的链上监控与提醒工具”，不连接钱包、不要求助记词。因此，无论审核侧还是用户侧，都很难仅凭外观将其与内核漏洞利用联系起来。
1.3 传播路径：KOL 邀请码与真机停留 5–7 分钟
公开推广信息显示，FomoPeek 主要通过币圈 KOL 及相关社群传播。用户需使用邀请码从 App Store 下载并注册，设置“安全码”、添加监控钱包，并在真机上操作数分钟，经审核后可领取 5–7 USDT。部分推广内容还特别强调“一台 iPhone 仅有一次机会”“同设备多号无效”“必须使用真机并停留 5–7 分钟”。
这一要求值得关注。样本中集成了名为 CicutaVirosaStrategy 的利用策略，对应的公开利用 cicuta_virosa 单次运行需要两分钟以上。因此，“必须真机、云手机无效、需要停留数分钟”的推广规则，与内核利用链需要在真实设备上持续运行一段时间的技术特征吻合。不过，该推广规则只能作为辅助线索，不能单独用于判定其恶意目的。
9 月中旬，公开社交平台已出现用户警告，2026-09-16 17:11 UTC，X 用户金灰(@GXingPing) 发帖称因下载 FomoPeek 软件出现被盗事件，并告诫尽快卸载软件。
(https://x.com/GXingPing/status/2100271397989998628)
早在用户集中反馈资产被盗之前，与此类事件相关的 iOS 数据提取能力便已被公开预警。2026 年 3 月 25 日，慢雾首席信息安全官 @im23pds 发布安全提醒：DarkSword 攻击工具已经泄露，可通过 HTTP 接口从 iOS 设备中提取并回传取证级数据。攻击者还可能结合社工或水坑攻击，诱导目标访问已被植入恶意代码的网站或页面，进而窃取 iPhone、iPad 中的数据并上传至攻击者控制的服务器。
(https://x.com/im23pds/status/2036624111968100402)
1.4 主体与时间线异常
公开资料显示，Apple 侧登记的 Seller 为 Porter Manufacturing, L.L.C.，开发者显示名为 WhaleScanv，其名下目前仅发现 FomoPeek 一款 App。
由于公开信息不足以确认该 Seller 背后的实际运营主体，本文不对其身份及与同名企业之间的关系作进一步归因。但从域名注册、隐私政策、应用发布及恶意模块植入时间来看，相关 Web 身份与发行基础设施均在较短时间内集中建立。
以下时间线值得警惕：
（FomoPeek 事件时间线）
时间 | 事件 |
2026-08-26 | 官网隐私政策标注的生效日期 |
2026-08-28 | 域名 fomopeek[.]com 注册（RDAP 记录） |
2026-08-29 | App Store 首次发布（1.0） |
2026-09-09 | 1.1 上线并首次携带恶意模块 |
2026-09-12 | 1.2 上线，沿用同一套恶意模块 |
2026-09-17 | 1.3 上线，两个 Framework 被整体移除 |
2026-09-18 | App Store 当前版本更新为 1.3 |
从域名注册到 App 上架仅约 10 天，且隐私政策“生效日期”早于域名注册两天。整个 Web 身份与发行链路是 8 月底到 9 月初集中搭建的。
1.5 隐私标签与自身隐私政策的矛盾
App Store 页面的“App 隐私”（App Privacy）区块显示为“未收集数据”，但 FomoPeek 官网隐私政策明确列出其处理的数据类型，包括：X-Device-Id（设备标识）、APNs 推送令牌、邮箱、密码（bcrypt 哈希）、昵称、二次验证安全码（bcrypt 哈希），以及用户添加的公开钱包地址、标签、阈值与事件偏好。
即使不考虑内核漏洞利用，面向 Apple 申报的“未收集数据”与其隐私政策中列明的收集范围也已互相矛盾。
二、版本时间线与投毒范围
我们在 1.1 与 1.2 的包内发现两个与业务功能无关的 framework：
（1.1 / 1.2 包内 Frameworks 目录）
（版本时间线与模块变化）
版本比对显示，1.1 与 1.2 携带的是同一套恶意模块，代码段与数据段一致；1.3 则将两个 framework 整体移除，IPA 体积由 10.47 MB 降至 1.81 MB。
主程序及两个 framework 均使用相同的 Apple 签名主体，原始 IPA 中还保留 FairPlay 加密元数据，说明恶意模块属于开发者提交至 App Store 的正式包内容，而非第三方重签名或侧载产物。
三、恶意模块分析
3.1 两个与业务无关的 Framework
两个模块分工明确：apptrace 负责 C2 通信，libapptracecore 负责内核攻击与数据采集。
libapptracecore 的命名空间分布说明其性质：它不是埋点、统计或反调试组件，而是一套从利用(exploit) 到内核访问(kernel)、权限与沙盒(permissions)、钥匙串(keychain)、采集与传输(acquisition) 的完整工具链。apptrace 承担与外部控制端的全部通信，两者组合成“通信 + 攻击”的植入体。
3.2 启动即加载，主程序不含调用痕迹
主程序的 Mach-O 加载命令以 LC_LOAD_DYLIB（非 weak）引用两个 framework：
@rpath/apptrace.framework/apptrace
@rpath/libapptracecore.framework/libapptracecore
这意味着无论业务代码是否调用，二者都会在 App 启动时被 dyld 加载进同一个进程。
另一方面，主程序侧确实不含显式调用痕迹：符号表中 1,048 个导入符号全部来自系统库，ObjC 类引用仅包含系统类，除上述两条加载路径外找不到框架的类名或方法名；框架自身也没有 ObjC 的 +load / +initialize，对 34 个 C++ 静态初始化函数（__mod_init_func）做三层调用追踪，也未触达利用与采集代码。
因此静态层面可确认：模块随 App 启动被强制加载进进程，且能力代码完整；实际触发时机与执行证据需结合真机动态验证。
3.3 内核攻击框架：8 种利用方案与版本自动匹配
libapptracecore 实现了 8 个利用策略类，均继承自 exploit::IExploitStrategy / KernelMachTaskExploitStrategyBase，并为每个策略内置"是否支持当前设备"的判定：
（IDA 中可见各利用策略的支持判定字符串）
8 种策略的版本窗口首尾相接，代码声明的覆盖范围为 iOS 12.0–18.7.2 以及 iOS 26.0–26.1。框架会根据系统版本和设备型号依次判断策略是否可用，并区分利用成功、利用失败及设备不受支持三种结果。
框架内置机型表还包含 iPhone16,1/16,2、iPhone17,1–17,5、iPad15,3–15,6、iPad16,1–16,6 等 2023–2025 年机型，说明适配目标并非老旧设备。
（8 种利用方案的 iOS 覆盖区间）
3.4 内核读写与权限提升
内核任务端口：Creating safe tfp0、testing new tfp0 port、Updated port for tfp0!、failed to allocate new tfp0 port
内核读写原语：kread (found kread_sem_index / error on kread)、kwrite、mach_vm_read_overwrite / mach_vm_write / mach_vm_allocate
利用面：IOSurfaceRootUserClient、IOSurfaceClient、IOAccelCommandQueue2、IOAccelSharedUserClient2
保护绕过：HSP4 patch exists.、Applied HSP4 patch.（PPL 绕过）
结构偏移来源：kernel::OffsetProvideriOS12 / 13 / 14 / 15 / 15_2 静态表，以及针对 iOS 16 及以上的运行时偏移计算分支（内部对 16、18、26 有专门处理）
提权：permissions::KernelUcredStealer、permissions::RORestrictedUcredPatcher、permissions::RO2RestrictedUcredPatcher（含 WeirdCsTrick / WeirdCredTrick）
3.5 沙盒逃逸与钥匙串解密
沙盒部分由 permissions::SandboxExtPatcher 完成, 目标权限串为 com.apple.app-sandbox.read-write。突破沙盒后, 进程即可读取本应用容器之外的路径。
钥匙串部分是整套框架中危害最直接的一环：
系统服务交互：AppleKeyStore 客户端初始化 (Initialized AppleKeyStore client、Device failed to start AppleKeyStore client with err ...)、keyBag、pkcs8ShroudedKeyBag
数据库解析：keychain::KeychainV3、KeychainV9、KeychainV11，对应不同 iOS 版本的钥匙串数据库格式
序列化结构：SecDbKeychainSerializedAKSWrappedKey、SecDbKeychainSerializedItemV7、SecDbKeychainSerializedMetadata、SecDbKeychainSerializedSecretData
解密与导出：keychain::GetRawKeychain、parsing::DecryptSFA、keychain::AgentKeyUnwrapper、acquisition::server::RawKeychainDecryptDataWriter
3.6 C2 通道 Bitbucket 死信箱 加密上报
在隔离设备（伪装为 iPhone 16 / iOS 26.1）上运行受影响版本后，我们抓到两条与业务完全无关的请求，并完整解密了其内容。
① 死信箱：从公开代码托管站点取加密后的 C2 地址列表
（Bitbucket 死信箱与 C2 地址的运行时解析流程）
GET hxxps://bitbucket[.]org/discordseven/text/raw/main/xxhVOn该仓库(bitbucket[.]org/discordseven/text) 为公开仓库，README 与 .gitignore 均为 Bitbucket 默认模板，仅用于伪装；仓库创建于 2026-08-04，提交者邮箱为 discdseven@outlook.com。其中的 xxhVOn 文件是加密后的 C2 地址列表：
文件为 48 字节的 AES-CBC 密文
客户端在启动后会用内嵌密钥将其解密，得到 C2 地址列表 ["hxxps://api-a95f0ed200f.assisaint[.]com"]
该文件历史上被修改过三次：2026-08-04（64 字节）、2026-08-06（48 字节）、2026-09-13（48 字节，即 1.2 发布次日）。
攻击者只要编辑这一个公开文件，就能更换全部受害端的 C2 地址，而无需发布新版 App。
② C2 上报：加密的设备信息与远程指令
（C2 配置接口的请求结构与关键字段）
该 C2 域名 assisaint[.]com 注册于 2026-09-12（正是 1.2 上架当天），注册商为 Cloudflare，并以前置方式隐藏源站；CT 日志中还可看到另一个同域子域 bp-a95010ced.assisaint[.]com（TrustAsia 签发的 90 天证书）。
③ 解密结果
客户端使用 CommonCrypto 的 CCCrypt（alg = kCCAlgorithmAES(0)、options = kCCOptionPKCS7Padding(1)，即 AES-CBC + PKCS7）对报文体加密。通过 hook 该函数，我们取得本会话密钥并解出双向明文：
（C2 通道解密结果——设备信息上报与远程指令）
项 | 值 |
算法 | AES-128-CBC + PKCS7 |
KEY | bc2c72b2260840b28bc9614aa2b8004b |
IV | 71ec8e3980754823aba30e62be55cf6a |
请求体 params 解密后为设备信息上报：
{"app_version":"1.0.5","app_pac":"com.fomopeek.app","app_uuid":"7A5475A0007346BCB6EDB30E43315999","timestamp":1789806193645,"machine":"iPhone 16","ios_version":"26.1"}响应 data 解密后为远程指令：
{"version":"1.0.0","min_close_exploit_version":"","exploit_enabled":false,"exploit_repeat_enabled":false,"exploit_test":false,"app_log_report_enabled":false,"exploit_repeat_interval":86400}动态验证确认：死信箱与 C2 请求全部由 apptrace 发出（multipart boundary 前缀为 ---AppTraceBoundary），而利用策略、内核读写、钥匙串解密与 40000 端口服务均位于 libapptracecore 中。
字段 | 含义 |
exploit_enabled | 漏洞利用总开关 |
exploit_repeat_enabled | 是否定期重复执行利用 |
exploit_repeat_interval | 重复间隔（秒），86400 = 24 小时 |
exploit_test | 测试模式开关 |
app_log_report_enabled | 是否回传应用日志 |
min_close_exploit_version | 版本闸门，达到该版本即关闭利用能力 |
需要说明的是，本次运行及 2026-09-19 08:23 的抓包中，exploit_enabled 均为 false；但该开关及其周期参数的存在，说明攻击者可通过服务端响应随时开启利用、调整执行周期或强制关闭，而无需更新 App。同时，测试虚拟设备自报画像（iPhone 16 / iOS 26.1）恰好落在 3.3 节所述 DarkSwordStrategy（16.7–18.7.2 与 26.0–26.1）的覆盖区间内。
3.7 远程采集目标 19 个钱包与笔记应用
为验证"开关打开后会发生什么"，我们通过 Frida 在解密回调中把响应里的 exploit_enabled / exploit_repeat_enabled / exploit_test 就地改写为 true，随后观察客户端行为。
客户端在下一次取回配置时，除了开关状态，还收到了一份采集目标清单（`collect_configs`）——这直接暴露了本次行动的意图：
（collect_configs 采集目标清单摘要，共 19 个 App）
C2 下发的 collect_configs 共包含 19 个采集目标，几乎全部为钱包类 App，涉及 Gate Web3、SafePal、OKX Wallet、MetaMask、Trust Wallet、imToken、TokenPocket、TronLink 等。
采集路径集中在 keystore、SQLite、MMKV、React Native 本地存储及 Keychain access group，并包含整个 Apple 备忘录容器 group.com.apple.notes。这些配置表明攻击目标是钱包密钥材料及用户保存的其他敏感信息，且采集范围可由服务端动态调整。
至此，恶意模块的攻击能力与 C2 下发的定向采集目标形成完整证据链。
3.8 外传链路：POST /api/upload/zip
触发采集后，我们捕获到发送至 /api/upload/zip 的 multipart 请求。其中，params 字段为 AES-CBC 加密的文件元数据，file 字段则是未额外加密的 ZIP 归档。
解密后的元数据显示，上传目标为 group.com.apple.notes，归档大小为 46,092 字节，并携带文件 MD5、设备 UUID、落地路径及时间戳。还原出的 ZIP 包含 NoteStore.sqlite、WAL 文件及相关配置文件，与 Apple 备忘录容器结构一致。
由此可以确认：样本会按照 C2 下发的清单读取目标容器，将结果打包暂存于自身沙盒，再上传至 /api/upload/zip。
（POST /api/upload/zip 的 multipart 字段结构）
我们从这份报文中还原出了归档本体，归档内容即 Apple 备忘录容器：
group.com.apple.notes/NoteStore.sqlite 307,200group.com.apple.notes/NoteStore.sqlite-shm 32,768group.com.apple.notes/.com.apple.mobile_container_manager.metadata.plist 577group.com.apple.notes/Library/Preferences/group.com.apple.notes.plist 127group.com.apple.notes/NoteStore.sqlite-wal / com.apple.notes.databaseopen.lock
至此，我们在隔离测试环境中验证了目标容器读取、文件打包及数据上传流程。结合框架中的内核利用、权限提升与沙盒逃逸代码，可以还原其设计链路：远程配置下发 → 内核利用与权限提升 → 目标数据采集 → 打包上传。
3.9 其余 C2 端点：应用清点与执行回传
除配置下发与数据外传端点外，我们还确认两个配套端点，共同构成“侦察 → 下指令 → 采集 → 回传”的完整 C2 协议。
① /api/device/apps：上报已安装应用清单
（POST /api/device/apps 应用清点请求要点）
该请求的 params 段用同一把 KEY/IV 解密后，是设备上全部 135 个应用的 bundle ID 列表：
{"app_uuid":"7A5475A0007346BCB6EDB30E43315999","apps":["com.apple.Home.HomeControlService","com.apple.CarCamera","com.debank.rabby-mobile-regression","com.apple.ScreenSharingViewService","com.okx.wallet", … 共 135 项 …]}
这份清单的作用很直接：服务端据此判断该设备装了哪些钱包，再决定下发哪一份 collect_configs。
② /api/device/report：执行结果回传与后续指令
（POST /api/device/report 的结果回传与后续指令）
③ 已确认的 C2 端点汇总
端点 | 方向 | 内容 |
GET bitbucket[.]org/discordseven/text/raw/main/xxhVOn | 取 | 加密后的 C2 地址列表（可随时轮换） |
POST /api/device/apps | 上报 | 设备已安装应用清单（135 项 bundle ID） |
POST /api/device/config | 双向 | 上报设备信息；取回 exploit_enabled 等开关与 collect_configs 目标清单 |
POST /api/device/report | 双向 | 回传执行结果；响应 data 为后续加密指令 |
POST /api/upload/zip | 上报 | 上传采集到的归档（params 为加密元数据，file 为明文 ZIP） |
3.10 C2 域名的注册与部署特征
对 C2 域名本身的基础设施调查结论如下：
项目 | 结果 |
主域名 | assisaint[.]com |
注册时间 | 2026-09-12 08:56 UTC（与 FomoPeek 1.2 上架同一天） |
注册商 | Cloudflare, Inc.；注册信息隐私隐藏，国家字段为 CN；DNSSEC 未启用 |
解析 | 104.21.73.21 / 172.67.137.159（Cloudflare 反向代理，无法据此确定源站 IP） |
证书 | 注册当天签发 *.assisaint[.]com 通配符证书（Let's Encrypt）；9 月 15 日追加 Sectigo 通配符证书 |
该域名注册时间较新，并采用注册信息隐私保护、Cloudflare 反向代理及快速证书部署，符合短期攻击基础设施的常见特征。域名注册日与 FomoPeek 1.2 上架日相同，可作为时间关联线索，但上述公开信息不足以判断源站位置或攻击者归属。
核对该域名的公开基础设施时，可以看到其中一个子域承载一套名为 Collect 的管理界面，其前端路由出现与设备、应用和密钥相关的条目（/machineApp、/machineApp/needBlast、/machineApp/walletAddress、/machineAppKeys、/machineStat、/mnemonic、/partner/account、/partner/home、/partner/machine/detail 等）：
（Collect 管理前端路由）
这说明该域名承载的并非普通业务 API，而是与设备采集、密钥相关数据配套的运营侧界面；其具体功能与字段本文不展开。
四、攻击链复盘
（FomoPeek 完整攻击链）
模块加载：App 启动时，apptrace 与 libapptracecore 被强制加载；
获取 C2：从 Bitbucket 获取密文并解密得到 C2 地址；
设备侦察：上报设备信息及已安装应用清单；
配置下发：获取漏洞利用开关、执行周期及采集目标；
利用与提权：选择匹配的内核利用策略，获得越权读取能力并突破沙盒；
采集与外传：读取目标 App 数据及 Keychain，打包后上传至 /api/upload/zip。
五、MistTrack 链上分析
通过对已收集到的链上数据进行追踪分析，本次事件中攻击者的盗取资金涉及多条链（TRON、Ethereum 及其他 EVM 兼容链等）。本小节只对主要的黑客地址(0x6d37f2C5e8F8546b648D317295565dA95975f4BB) 进行分析。
据 MistTrack 数据显示，该地址总收入为 579,984.34 USDT，自 9 月 15 日起开始活跃。
其资金活动覆盖 Ethereum、BNB Chain、Arbitrum 等多条链，截至发文时仍有资金持续转入。当前余额如下：
该地址的大部分资金被汇集至 Ethereum 网络，其余链上的资金则主要通过 OKX DEX、Meson.fi、Relay.link、Mayan Finance 等跨链/兑换平台转换为 USDT 后跨链至 Ethereum。
随后，该地址将汇集的 USDT 分批转出至以下下游地址：
（1）0x0A571f0Fa18D7EB9abcc1e98a0Bb9bC15534BbAe
该地址当前余额 24,352 USDT。值得注意的是，该地址早在 5 月 23 日就已开始活跃，早于本次事件的主要攻击时间窗口。
与 FixedFloat、cce.cash、OKX 等存在交互：
此外，有一笔较大金额 111,458 USDT 转出到地址 0x4c73d7e8ef0e61129403e219debc597fd43aa0ec 再转入 USDT0: UsdtOFT 进行跨链。
跨链接收地址为 TRON 地址 TF2hm96RC2Aqon9FeQjGidofoC2J1zM8v1。该地址总接收 2,123,570.8821 USDT，后续经多个地址分散并转入疑似 OTC 平台。
（2）0x0DF6aC2e2856114228756947d1b1d9Ff63eA3e68
该地址总接收159,000 USDT：
资金全部转入 FixedFloat：
（3）0x2d53113c89c83c520c17b8bbcdc22aa0518a38be
该地址总接收 47,028 USDT：
其中 10,000 USDT 转入 KuCoin，剩余 37,028 USDT 转入 FixedFloat：
（4）0x111faeb95cd0786593433bcc762dc5c1debf541c
该地址总接收 227,154 USDT：
215,000 USDT 转入 FixedFloat，10,000 USDT 转入 cce.cash：
我们将持续关注上述地址的资金动态。如果您曾安装过 FomoPeek 且近期遭遇资产被盗，可将被盗地址和黑客地址提交至以下链接：https://aml.slowmist.com/cn/recovery-funds.html。
六、威胁指标 IOC
URL :
hxxps://api-a95f0ed200f.assisaint.com/api/device/config
hxxps://bp-a95010ced.assisaint.com
hxxps://admin-e433360cb0e.assisaint.com
hxxps://customer-c1cb36b5.assisaint.com
hxxps://bitbucket.org/discordseven/text/raw/main/xxhVOn
Domain:
assisaint[.]com
api-a95f0ed200f[.]assisaint.com
bp-a95010ced[.]assisaint.com
admin-e433360cb0e[.]assisaint.com
customer-c1cb36b5[.]assisaint.com
File:
FomoPeek-1.1-891048157.ipa
MD5: fce99b45709a6f8e241175be0c121874
SHA-256: d6b6407b4c97697fdde174cbc190b6433315470f58df6b483ac5b806f35e20f9
FomoPeek-1.1.ipa
MD5: f5bdaed5953033ac8c3256f2933b9a81
SHA-256: ca5dfd0fa7a16f26f5b369516f5b8bcac1d5a6fe01a8511a5ededf4cd2c0d042
FomoPeek-1.2.ipa
MD5: 38a8a5ddecd9a5626b42dae593ac28f6
SHA-256: 48f9d5623af1518e774d57c41e6e0b915a7e9f896909bf596a9b27de5022911e
apptrace
MD5: 645b9053390246995c2cb7a9b9eddf40
SHA-256: 764663ff5c8bd1bdf33bbd1ec352ce262a4fe79695456f2612dc27c35840ab9d
libapptracecore
MD5: 03d67a68b5e8507dbbe36f2a4b41aca0
SHA-256: f0b3be01e8597f7f35ca36c009f68e7004527fe4a01d4349a01e211ca16de1e2
七、排查与处置建议
7.1 用户侧
如果您的设备曾安装过 FomoPeek 1.1 或 1.2 版本，请注意：卸载或升级到 1.3 并不等于设备已经安全，该框架一旦被成功利用，其读取到的数据已经离开设备。
1. 立即停止使用该应用，且不要重新安装；
2. 在未安装过该应用的安全设备上新建钱包、生成全新助记词，并转移资产；旧助记词与私钥一律视为已泄露，禁止复用；
3. 逐一排查各链账户的异常转账与授权记录，撤销不再使用的授权；
4. 更换在该设备上使用过的密码与登录凭证，开启二次验证；
5. 检查设备是否安装过配置描述文件 / MDM、是否侧载或越狱；必要时抹机重装系统；
6. 保留设备与相关证据（App 版本、安装时间、异常交易记录），以便进一步核查；
7. 如发现异常资产活动，请立即联系相关平台官方客服。
7.2 平台与生态侧
1. 将文件哈希、类名、关键字符串与网络特征纳入样本库、EDR 与流量检测规则；
2. 对安装过 FomoPeek 1.1 或 1.2 的用户下发定向风险提示，并按凭据泄露事件处置；
3. 阻断 assisaint[.]com 及其子域、bitbucket[.]org/discordseven/*；
4. 从 2026 年 9 月 9 日起检索 Bitbucket 死信箱访问记录，从 9 月 12 日起检索 *.assisaint[.]com 相关 DNS、代理、EDR、VPN 与移动设备日志。若日志保存周期允许，可进一步回溯至 8 月 4 日，排查该 Bitbucket 仓库及历史 C2 配置的访问情况。
八、总结
通过静态分析与动态验证，我们确认 FomoPeek 1.1 与 1.2 植入了 `apptrace` 和 `libapptracecore` 两个恶意模块，具备远程配置、内核漏洞利用、沙盒逃逸、Keychain 解密及跨应用数据采集能力。
在隔离环境中触发相关功能后，样本从 C2 获取了针对 19 个钱包及笔记应用的采集清单，并将 Apple 备忘录容器打包上传至 `/api/upload/zip`，验证了从远程配置、越权读取到数据外传的完整技术链路。
FomoPeek 1.0 中未发现上述模块，1.1 首次植入，1.2 继续沿用，1.3 已整体移除。曾使用 1.1 或 1.2 的用户，仅卸载或升级应用无法排除历史泄露风险，建议将相关助记词、私钥及敏感凭据按已泄露处置。
常见问题 Q&A
Q1：这次事件是什么时候发生的？
目前可以明确确认的风险时间窗口是 2026 年 9 月 9 日至 9 月 17 日。
FomoPeek 1.0 于 8 月 29 日首次上架，当时未发现相关恶意模块；9 月 9 日发布的 1.1 版本首次植入 apptrace 和 libapptracecore，9 月 12 日发布的 1.2 版本继续携带同一套恶意代码；直到 9 月 17 日发布 1.3 版本后，这两个 Framework 才被整体移除。
9 月 16 日，公开社交平台已经出现用户因安装 FomoPeek 后发生资产被盗的预警。由于并非所有受害者的安装时间和资产被盗时间都能够完整获取，因此目前无法据此确定最早一次实际攻击发生的具体时间。
Q2：哪些版本受到影响？
从 App 版本来看，明确受到影响的是 FomoPeek 1.1 和 1.2。
1.0：未发现恶意模块；
1.1：首次植入恶意模块；
1.2：继续携带同一套恶意模块；
1.3：相关 Framework 已被整体移除。
从攻击框架代码声明的 iOS 覆盖范围来看，其内置 8 套利用策略，覆盖 iOS 12.0–18.7.2，以及 iOS 26.0–26.1，并会根据设备型号和系统版本选择对应的利用策略。
需要注意的是，FomoPeek 在 App Store 页面标注的系统要求为 iOS 16.0+，因此“攻击框架具备的理论覆盖范围”和“FomoPeek 实际可以通过 App Store 安装到的设备范围”不是完全相同的概念。
Q3：攻击可能通过哪些途径发生？
在本次 FomoPeek 事件中，已经确认的传播入口就是 App Store 官方版本本身，并非第三方重签名、企业签名或侧载安装包。恶意 Framework 与主程序使用相同的 Apple 签名主体，原始 IPA 中也保留了 FairPlay 加密元数据。
FomoPeek 主要通过币圈 KOL、社群、邀请码以及少量 USDT 奖励吸引用户安装，并要求用户使用真机运行数分钟。
但从攻击技术本身来看，这类 iOS 内核利用并不一定只能藏在某一个 App 中。类似能力理论上还可以通过：恶意或被投毒的 App、供应链组件、钓鱼页面、被入侵的网站，以及针对特定人群布置的水坑页面等入口触发。
本文此前提到的 DarkSword 相关公开预警中，也曾指出攻击者可能结合社工或水坑攻击，诱导目标访问被植入恶意代码的网站或页面，进一步窃取 iPhone、iPad 中的数据。
因此，不要简单把“来自 App Store”或“来自平时经常访问的网站”理解为绝对安全。
Q4：什么是“水坑攻击”？
“水坑攻击”(Watering Hole Attack) 的思路并不是直接去寻找每一个受害者，而是先找到目标人群经常访问、并且比较信任的地方。
例如攻击者想针对某一批加密货币从业者，可能先分析这些人经常访问哪些行业网站、工具站、社区、项目官网或活动页面，然后寻找其中可以入侵或植入恶意代码的目标。
一旦这些正常网站被控制，受害者只是像平时一样访问网站，就可能进入攻击链。
这个名字来源于自然界的“水坑”：捕食者不需要追逐每一只猎物，只需要守在动物经常喝水的地方。
对于移动设备而言，这个“水坑”也可以进一步理解为一种更广义的可信入口：它可能是一家熟悉的网站，也可能是一个长期使用的 App、第三方 SDK、社区链接，甚至是正常应用的一次更新。
Q5：类似风险是否只存在于 FomoPeek？
不是。
FomoPeek 更值得关注的地方，并不只是某一个钱包用户是否安装过这一款 App，而是它再次说明：攻击入口可能隐藏在看起来完全正常、甚至来自官方应用商店的应用中。
公开案例中，ComeCome（拜托拜托） 就提供了另一个值得关注的样本。公开分析显示，这是一款面向迪拜等地区华人用户的外卖 App，其 2.9.3 版本被发现包含名为 DKStatistics 的隐藏组件，具备突破 iOS 沙箱并访问钱包 App、WhatsApp 和 Apple 备忘录等数据的能力；公开页面同时披露了相关链上资金流转情况。需要说明的是，该网站也明确区分了“可以公开核对的技术与链上事实”和“无法据此直接归因实际攻击者”的边界。
这类案例给出的提醒是：
“水坑”并不一定长得像一个危险的网站。它可能就是你每天打开的网站、工具、外卖 App、社区链接，甚至是从官方商店下载的软件。
从传统定义上讲，FomoPeek 和 ComeCome 更接近 App 投毒 / 可信渠道投毒，而不是经典的网页 Watering Hole；但背后的攻击思路非常接近——先进入目标群体信任和高频使用的入口，再等待目标主动进入攻击环境。
所以真正需要警惕的并不只是某一个 FomoPeek。水坑可能存在于任何被目标人群长期信任的地方。
ComeCome 公开案例可参考：https://comecome.icu/
关于 MistEye
MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控平台，通过 API 提供开源包生态的恶意活动检测与供应链风险预警能力。
本次行动涉及的全部恶意包及 IOC 已接入 MistEye 威胁检测引擎，开发者可通过 API 对项目依赖进行自动化检测，快速判定是否命中已知恶意包并获取处置建议。
📖 API 文档：https://app.misteye.io/api-docs
🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan轻量级 CLI 工具，一行命令扫描项目依赖与全局安装包中的已知恶意包，支持 npm / PyPI / Cargo / Go / RubyGems 生态
🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsAI 编码助手安全技能包，在依赖安装与 URL 访问前自动触发 MistEye 安全检测
🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-GuardDNS 安全防护工具，检测恶意域名与风险访问，识别钓鱼、C2 等网络威胁
本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。
