事件概述
2026 年 9 月 1 日,一个名为「极点云 PolarNode」的所谓云服务活动开始在 VPS、运维、IT 和加密货币相关社区传播。
活动页面位于 event.polarnode.vip,宣传内容是:
完成内测预约,前 5,000 名用户均可获得免费 VPS,最高赠送 3 年使用权。
从表面上看,这是一个典型的新云厂商拉新活动。页面提供服务器配置、节点区域、带宽、内测倒计时和邀请奖励,并通过「邮箱预约 + 邀请码裂变」鼓励用户主动传播链接。
但对落地页以及后续加载资源进行静态取证后,可以看到完全不同的一面。
event.polarnode.vip 会在页面完成初始渲染后,通过 Next.js 自动引入 https://lk.wyincc.com/lk.js。这段 JavaScript 并不是普通的统计或业务脚本,而是整条 iOS 攻击链的入口。
进一步对 lk.js 以及其级联加载的 dist/ 目录资源进行反混淆和静态分析后,可以确认,样本中包含一套针对 iOS 18.6 / 18.6.1 / 18.6.2 的完整浏览器利用框架。
攻击过程可以概括为:
PolarNode 落地页 → 自动加载 lk.js → iOS/Safari 环境识别 → 隐藏 iframe → JavaScriptCore RCE → GPU 沙箱逃逸 → 内核任意读写 → PAC 绕过与高权限执行 → 注入 app.js → 窃取敏感数据 → C2 回传。
最终载荷直接针对 Keychain、短信、通讯录、相册、备忘录以及 imToken、TronLink 等加密货币钱包。
从攻击链的模块化程度、完整内核偏移表以及源码中出现的中文开发注释来看,这并不像一个简单的网页木马,而更接近一套经过工程化封装的移动端 Exploit Kit 与数据窃取载荷组合。
需要特别说明的是:本文分析基于公开可访问页面及 CDN 样本的被动下载和静态取证完成,未主动触发漏洞利用代码。
PolarNode 的攻击活动特征
本次活动的核心特征如下。
| 项目 | 内容 |
|---|---|
| 活动 | PolarNode「免费 VPS」钓鱼 + iOS 利用 |
| 发现时间 | 2026-09-01 |
| 诱饵 | 仿冒云服务商活动页面 |
| 前端框架 | Next.js / Turbopack |
| 投递方式 | next/script 自动加载第三方 JavaScript |
| 利用入口 | WebKit / JavaScriptCore |
| 直接命中系统 | iOS 18.6 / 18.6.1 / 18.6.2 |
| Build | 22G86 / 22G90 / 22G100 |
| 利用能力 | Browser RCE → Sandbox Escape → Kernel R/W |
| 最终目的 | 隐私窃取、账号凭据获取、加密货币盗取 |
| 开发特征 | 中文注释、大规模内核偏移表 |
| C2 | 13.248.210.49:36887、166.117.225.238 |
| 恶意基础设施 | lk.wyincc.com |
| 诱饵基础设施 | *.polarnode.vip |
样本中利用链的结构与公开披露的 DarkSword iOS Exploit Kit 高度吻合,涉及的主要漏洞包括 CVE-2025-43529、CVE-2026-20700、CVE-2025-14174、CVE-2025-43510 和 CVE-2025-43520。
这些漏洞在最初修复和披露时包含多个 0day,但截至本次分析时间,它们已经成为公开并获得补丁修复的 n-day。
因此,这次 PolarNode 活动真正值得关注的地方并不是「攻击者仍然掌握 0day」,而是:
已公开的高价值 iOS Exploit Chain 正在被重新封装,用于攻击长期未更新系统的普通用户。
免费 VPS为什么是一个很合适的诱饵?
PolarNode 的落地页 event.polarnode.vip 是一个标准的 Next.js 单页应用,自称「极点云 PolarNode|内测预约」。
整个页面在视觉和营销逻辑上都在模仿真实云厂商,包含 VPS 规格、CPU / 内存配置、带宽、硅谷 / 首尔 / 香港节点、内测倒计时、免费名额以及邀请返利等内容。
它甚至设计了完整的裂变体系。
提交预约
用户只需要填写邮箱,同时页面强调「每个邮箱、每个 IP 仅可预约一次」,制造活动名额有限的感觉。
分享邀请
预约完成后生成专属邀请链接。每成功邀请一名用户,可以增加一个月 VPS 使用权,最多增加 12 个月。
等待「开放内测」
页面宣称将在 2026 年 9 月 9 日 10:00 正式开启内测,并通过预约邮箱发送领取通知。
按预约顺序领取 VPS
整个设计与正常 SaaS 或云服务产品的 Pre-launch Campaign 非常接近。
但从当前能够获取到的站点信息看,这个所谓云厂商并没有表现出与真正 VPS 服务商相匹配的运营基础。
| 项目 | 情况 |
|---|---|
| 公司主体 | 未发现 |
| 备案 / 注册信息 | 未发现 |
| 联系方式 | 未发现 |
| 客服入口 | 未发现 |
| 售后渠道 | 未发现 |
| 核心页面 | 内测预约 |
| 关键技术行为 | 自动加载第三方 Exploit Loader |
因此,这个站点的核心作用更像是:把目标用户送入后面的浏览器 Exploit Chain。
而「免费 VPS」本身又是一个相当精准的人群筛选条件。会对此类资源感兴趣的用户,往往与开发者、运维人员、服务器用户、代理 / 节点用户、区块链用户以及加密货币持有者高度重合。
这意味着攻击者可以用一个低成本诱饵,同时完成技术用户筛选和加密资产用户筛选。
这与后续载荷中大量针对钱包、Keychain 和 2FA 的代码形成了明显闭环。
页面并不等待用户点击,而是直接加载恶意脚本
对落地页 HTML 进行检查,可以确认页面预加载了 https://lk.wyincc.com/lk.js,并通过 Next.js next/script 组件以 afterInteractive 策略加载。
afterInteractive 的含义是:页面完成初始 hydration、进入可交互状态后自动加载对应脚本。
因此,用户并不需要继续点击「预约」「领取」或其他按钮,只要访问落地页,lk.js 就会进入浏览器上下文。
从攻击分类来看,这种场景更接近 Drive-by Exploitation,而不是消息层面真正意义上的「零点击」攻击。
用户仍然需要主动打开攻击链接,但从页面打开以后开始,利用链本身已经不要求额外点击、安装应用、安装描述文件或者授权危险权限。
这也是这类浏览器攻击链与普通钓鱼页面最大的区别。
投递脚本 lk.js
本次获取到的核心 Loader 信息如下。
| 项目 | 内容 |
|---|---|
| 文件 | lk.js |
| 类型 | JavaScript Exploit Loader |
| 文件大小 | 48,878 Bytes |
| SHA-256 | 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70 |
| 托管位置 | lk.wyincc.com |
| 加载方式 | afterInteractive |
lk.js 自身使用了较重的 JavaScript 混淆,其主要特征包括字符串数组、Base64、RC4、动态字符串索引、十六进制算术以及控制流扰动,代码结构与 obfuscator.io 生成的混淆模式高度接近。
其中核心解码函数为 a0_0x18cf(idx, key),对应字符串池为 a0_0x23be。
通过提取解码函数并在本地 Node.js 环境中批量还原,可以恢复出大量真实字符串和主要控制逻辑。
lk.js 首先判断访问者是不是目标设备
反混淆后可以看到明显的平台筛选逻辑。
脚本会检查 User-Agent、浏览器环境、iOS 特征以及 Safari 相关属性,其攻击目标明显集中在 iOS + Safari。
不同平台的行为可以概括如下:
| 访问环境 | 可能行为 |
|---|---|
| Windows / macOS 桌面浏览器 | 展示正常活动页面 |
| Android | 大概率不进入完整利用链 |
| 非目标浏览器 | 停止后续 Exploit |
| 目标 iOS Safari | 继续加载漏洞利用模块 |
这类 Target Filtering 对攻击者非常有价值,因为它能够同时减少无效利用、自动化扫描曝光、桌面安全沙箱触发以及安全研究人员意外命中的概率。
因此,仅使用桌面 Chrome 打开 PolarNode 页面,很可能看不到真正的恶意行为。
隐藏 iframe:真正的利用代码并不运行在主页面
确认目标环境后,lk.js 会继续创建隐藏 iframe,并加载 sandbox.html、group.html 等资源。
主页面与 iframe 之间通过 postMessage() 传递 exploit 阶段状态和相关配置。
从整体设计来看,可以将页面划分为两层:
| 层级 | 主要职责 |
|---|---|
| PolarNode 主页面 | 社会工程、用户筛选、Loader |
| 隐藏 iframe | Exploit Runtime 与后续漏洞利用 |
这种结构有几个明显优势:
- 诱饵页面与 Exploit 代码解耦;
- 可以独立升级漏洞利用模块;
- 主页面源码更加干净;
- 自动化扫描如果只抓取主页,容易遗漏真正的利用链;
- 独立文档更方便控制 Exploit 生命周期与运行状态。
dist/chunks/ 中是一套完整的利用框架
sandbox.html 会进一步加载 dist/chunks/ 目录下的多个 JavaScript 模块。
静态分析后可以看到非常清晰的职责划分。
| 文件 | 大小 | 主要用途 |
|---|---|---|
vendor.js | — | offsets、slide、chipset、PAC / dlopen 等原语 |
runtime.js | 429 KB | Exploit Orchestrator、阶段机、rce_offsets |
framework.js | 351 KB | SBX0、GPU 沙箱逃逸、Mach IPC |
common.js | — | SBX1 与 Kernel R/W 原语 |
sbx1_main.js | — | 内核阶段主流程 |
app.js | 540 KB | 最终数据窃取组件 |
runtime-legacy.js | — | 旧版兼容 |
polyfill.js | — | 兼容层 |
platform_module.js | — | 平台相关逻辑 |
utility_module.js | — | 公共功能 |
从模块数量和体积来看,这已经远远超过一般 Web 恶意脚本,更像是一套由 Exploit Runtime、设备兼容层、Kernel Exploitation Framework 和最终 Payload 共同组成的完整攻击框架。
rce_offsets:78 套设备与系统组合
整个利用框架中一个非常重要的结构是 rce_offsets。
这是判断 Exploit 工程成熟度的重要证据之一。
样本中可以直接确认以下三个系统版本:
| 系统版本 | Build |
|---|---|
| iOS 18.6 | 22G86 |
| iOS 18.6.1 | 22G90 |
| iOS 18.6.2 | 22G100 |
按照样本中的设备配置统计,约有 26 款设备 × 3 个系统版本,共 78 个设备 / 固件组合。
每个组合又包含约 106 个符号、结构或者 gadget 偏移,同时按照约 8 类 SoC / 设备族进行划分。
这些 Offset 涉及内核函数、Kernel Structure、Gadget、Kernel Slide、Chipset 差异以及 PAC 相关原语。
这类 Offset Table 是现代 iOS Kernel Exploit 工程中非常重要的一环。
一个漏洞 PoC 能够在研究设备上成功,并不意味着它可以直接用于真实攻击。真正需要解决的是不同 iPhone、不同 SoC、不同 iOS Build 和不同 Kernel Cache 之间的大量差异。
因此,能够为多个系统 Build 和数十款设备准备完整偏移表,意味着攻击者已经把漏洞从研究性质的 Exploit PoC 推进到了可以工程化投放的阶段。
从浏览器一路打到 Kernel
结合模块名、阶段机和内部注释,整个利用链可以还原为五个主要阶段。
| 阶段 | 行为 |
|---|---|
| 1 | Safari / WebKit 触发 JavaScriptCore RCE |
| 2 | SBX0 借助 GPU / WebGL / Mach IPC 完成沙箱逃逸 |
| 3 | SBX1 构造 Kernel Arbitrary Read / Write |
| 4 | 利用 PAC Bypass、dlopen 等原语扩展执行能力 |
| 5 | 注入高权限进程并运行 app.js |
第一阶段解决的是「如何从网页 JavaScript 获得原生代码执行能力」。
第二阶段解决的是「如何逃离浏览器沙箱」。
第三阶段继续突破到 Kernel,并构造任意读写。
最后再通过 PAC 绕过、高权限上下文和进程注入,把最终窃取模块送入更高权限的系统环境。
因此,这不是一个单独的 JavaScriptCore RCE,而是一条完整的 Browser-to-Kernel Full Chain。
SBX0:GPU 沙箱逃逸
利用链中的 framework.js 与 SBX0 阶段相关。
静态代码中能够看到 OffscreenCanvas、WebGL、Mach IPC 和 GPU Process 等相关逻辑。
这一阶段的主要任务,是利用 GPU / WebGL 攻击面构造新的进程间通信能力,并进一步突破浏览器初始沙箱。
在现代 iOS 中,即使攻击者已经获得 WebKit 或 JavaScriptCore RCE,也不意味着能够直接读取系统中的 Keychain、短信或者钱包数据。
浏览器渲染环境本身受到严格的 Sandbox 隔离,因此必须继续跨越进程和权限边界。
SBX1:获得内核任意读写
后续 common.js 与 sbx1_main.js 进入 Kernel Exploitation 阶段。
代码中可以看到 Kernel Offset、Kernel Read、Kernel Write、PAC Primitive 和 dlopen Primitive 等相关逻辑,并出现 {{LPE_64BITE}} 这类模板化占位符。
这些特征说明整套框架具备明显的 Exploit Pipeline 设计,而不是针对某一台设备临时硬编码出来的一次性脚本。
最终载荷 app.js 才是攻击者真正关心的部分
漏洞利用只是手段,真正决定攻击意图的是最终的 app.js。
该文件约 540 KB,采用 webpack 打包,并保留了部分 ./src/** 模块结构。
静态分析中可以确认它直接访问多个 iOS 高价值数据源。
| 目标 | 相关证据 |
|---|---|
| Keychain | keychain-2.db、kSecClass、SecItemCopyMatching |
| SMS | sms.db |
| 通讯录 | AddressBook、Contact |
| 相册 | Photo / Camera Roll |
| 备忘录 | Note |
| 钱包 | im.token、tronlink、global.wallet |
| 文件系统 | /private/var、/var/mobile、Library |
部分关键字出现频次也非常高。
| 关键字 | 引用次数 |
|---|---|
| Keychain | 79+ |
| Photo | 1659+ |
| Contact | 241+ |
2fa | 60+ |
这些数据目标已经非常清楚地表明:攻击者的主要目的并不是控制设备本身,而是获取身份认证信息、隐私数据以及能够直接变现的加密资产。
为什么 Keychain 很关键
Keychain 是 iOS 最核心的敏感数据存储体系之一。
正常情况下,应用只能访问属于自身权限范围内的 Keychain Item。
但一旦攻击者已经完成 Browser RCE、Sandbox Escape、Kernel R/W 和高权限进程执行,原本依赖应用沙箱隔离的安全边界就会被大幅削弱。
样本中同时出现 keychain-2.db、kSecClass 和 SecItemCopyMatching,说明攻击逻辑并不只是寻找某个 App 自己的配置文件,而是在针对 Keychain 数据体系本身。
这类数据进一步可能关联到 Token、登录凭据、Session、应用 Secret 以及钱包相关认证材料。
加密货币钱包是明确目标
样本中直接出现 im.token、tronlink 和 global.wallet。
这并不是模糊意义上的「可能对钱包感兴趣」,而是明确存在针对 imToken、TronLink 和通用钱包的数据访问逻辑。
这也让「免费 VPS」这个诱饵的选择显得非常合理。
整个用户筛选逻辑实际上可以理解为:
对免费 VPS 感兴趣 → 技术用户概率上升 → 服务器 / 节点用户概率上升 → 与加密社区重合度上升 → 钱包持有概率进一步上升。
随后利用 iOS Exploit 直接跳过传统钱包钓鱼常见的假签名、假 WalletConnect 或假助记词页面,转而尝试从设备内部获取高价值信息。
C2 与配置下发
样本中可以确认两个主要网络指标:
| 地址 | 角色 |
|---|---|
13.248.210.49:36887 | 主 C2 / 通信端点 |
166.117.225.238 | 备用或关联端点 |
同时还能看到 heartbeat、site_host、uid、device_source 和 SDK_PORT 等与通信相关的配置字段。
其中 device_source 示例值为 782391,默认 _SDK_PORT 为 80。
整体通信逻辑包括:
- 心跳;
- Exploit 状态上报;
- 设备信息上报;
- 服务端配置下发;
- 数据回传。
两个 IP 均与 AWS Global Accelerator 相关基础设施存在关联。
这种设计可以一定程度上将访问入口与真实后端解耦,因此从检测角度来看,IP IOC 更适合快速止血,而不能作为长期唯一的检测手段。
这套 Exploit Chain 与 DarkSword 高度吻合
将当前样本与公开披露的 DarkSword iOS Exploit Kit 进行结构比对,可以看到多个高度一致的特征:
- JavaScript 全链;
- RCE Worker;
- SBX0;
- SBX1;
- GPU 沙箱逃逸;
- Kernel R/W;
- PAC 绕过;
- 大规模 Offset Table;
- 高权限 Payload Injection。
其中最直接的一个指纹就是 sbx1_main.js。
该文件名直接存在于本次样本中,而在 DarkSword 的公开分析中,sbx1_main.js 同样对应内核阶段利用逻辑。
从利用链架构上,两者都遵循 RCE → SBX0 → GPU Sandbox Escape → SBX1 → Kernel Read / Write → LPE 的分阶段设计。
结合 CVE 修复时间、模块命名以及代码结构,本次样本极可能是 DarkSword 体系的一种 18.6.x 适配或再封装版本。
DarkSword 相关漏洞映射
根据样本模块与公开技术资料,可以做出如下对应。
| 阶段 | 模块 | CVE | 漏洞类型 | 组件 |
|---|---|---|---|---|
| Browser RCE | rce_worker_18.6.js | CVE-2025-43529 | JavaScriptCore DFG JIT UAF | WebKit / JSC |
| 备用 RCE | rce_module.js | CVE-2025-31277 | JIT 类型混淆 | WebKit / JSC |
| PAC Bypass | rce_worker_* | CVE-2026-20700 | dyld 内存破坏 | dyld |
| SBX0 | sbox0_main.js | CVE-2025-14174 | ANGLE / WebGL 越界访问 | GPU / WebKit |
| SBX1 | sbx1_main.js | CVE-2025-43510 | XNU CoW 缺陷 | XNU |
| LPE | pe_main.js | CVE-2025-43520 | XNU VFS Race | XNU |
相关漏洞后续分别在 iOS 18.7.2、18.7.3、26.1、26.2 和 26.3 等版本中得到修复。
需要强调的是,这里的「0day」指的是漏洞首次被利用或披露时的状态。截至 2026 年 9 月,本次活动所使用的这些漏洞已经属于 n-day:漏洞已经公开,也已有补丁,但仍然能够攻击没有及时升级的设备。
当前样本直接适配的系统版本
从 rce_offsets 中能够直接确认:
| 系统 | Build |
|---|---|
| iOS / iPadOS 18.6 | 22G86 |
| iOS / iPadOS 18.6.1 | 22G90 |
| iOS / iPadOS 18.6.2 | 22G100 |
对应约 26 类设备组合,覆盖 iPhone XS 及之后的多代 iPhone,并涉及对应的 iPad 产品线。
因此,对于访问过页面的用户来说,最重要的并不是判断「我是不是某一代 iPhone」,而是确认:
访问页面时所运行的 iOS Build 是否处于样本适配范围,或者其他仍然存在相关漏洞的旧版本。
DarkSword 的影响范围并不仅限于 18.6.x
PolarNode 当前样本确认的目标集中在 18.6.x,但 DarkSword 相关漏洞的整体影响范围更大。
| 漏洞 | 主要修复节点 |
|---|---|
| CVE-2025-43529 | iOS 18.7.3 / 26.2 |
| CVE-2025-14174 | iOS 18.7.3 / 26.2 |
| CVE-2025-43510 | iOS 18.7.2 / 26.1 |
| CVE-2025-43520 | iOS 18.7.2 / 26.1 |
| CVE-2026-20700 | iOS 26.3 |
因此,不能简单把安全判断理解为「18.6.2 以后全部安全」。
更合理的用户建议始终是:
升级到 Apple 当前仍支持的最新安全版本。
从商业监控 Exploit 到网络犯罪工具
DarkSword 最初公开披露时,其使用场景更接近商业监控和定向情报攻击。
公开研究中出现过多个相关植入家族。
GHOSTKNIFE
相关攻击集群使用仿冒 Snapchat 页面进行投递,后续载荷可获取账户、消息、浏览器数据、地理位置和麦克风录音,同时使用 ECDH + AES 等机制进行 C2 通信,并包含清理崩溃日志等反取证行为。
GHOSTSABER
相关植入支持大量 C2 指令,包括文件窃取、SQLite 查询、相册数据获取和运行时扩展模块。
GHOSTBLADE
数据获取范围更加广泛,涉及 iMessage、Telegram、WhatsApp、Safari History、Cookie、Keychain、Location、Wi-Fi、健康数据以及 Cryptocurrency Wallet。
而 PolarNode 最值得注意的变化是:
Exploit 框架本身并没有发生根本变化,但攻击目的明显从监控转向了直接金融变现。
攻击者仍然复用 RCE、Sandbox Escape、Kernel 和 Payload Injection 的技术链,但最终 Payload 的优先目标变成了 Wallet、Keychain、2FA 和 Crypto Account。
这正是高级漏洞利用框架扩散后非常典型的演化过程。
为什么公开后的 Exploit Kit 反而可能更危险
漏洞生命周期经常被理解成「0day → 厂商修复 → 技术公开 → 事件结束」。
现实情况往往并不是这样。
更常见的演变路径是:
| 阶段 | 变化 |
|---|---|
| 0day 阶段 | 用于高价值、定向攻击 |
| 厂商修复 | 原始攻击窗口开始缩小 |
| 技术公开 | 漏洞原理与利用方式被更多人掌握 |
| Exploit 泄露 / 商品化 | 攻击门槛快速下降 |
| n-day 阶段 | 开始攻击大量未更新设备 |
对于高端攻击组织来说,漏洞公开可能意味着独占价值下降。
但对于普通犯罪团伙来说,漏洞公开反而可能意味着终于可以低成本获得成熟利用代码。
PolarNode 所呈现出的正是这种风险。
基础设施关联
目前能够关联到的主要资产如下。
| 资产 | 作用 |
|---|---|
polarnode.vip | 诱饵主域名 |
event.polarnode.vip | 活动落地页 |
lk.wyincc.com | Loader 与 Exploit CDN |
13.248.210.49:36887 | C2 |
166.117.225.238 | 关联网络端点 |
从整体基础设施关系来看,polarnode.vip 负责社会工程,event.polarnode.vip 承载 Next.js 落地页,lk.wyincc.com 负责 Exploit Delivery,而后续窃取数据再通过 C2 基础设施进行回传。
因此,从防御角度看,最好同时从 Domain、URL、IP、Port、Hash 和 Behavior 多个层面进行检测。
从 ATT&CK 视角看整个攻击链
如果按照 MITRE ATT&CK 思路拆解,可以得到如下攻击生命周期。
| 阶段 | 行为 | 表现 |
|---|---|---|
| 侦察 | 筛选目标人群 | VPS / IT / Crypto 社区 |
| 资源开发 | 注册基础设施 | 新域名、CDN、C2 |
| 资源开发 | 获取攻击能力 | DarkSword 类 Exploit Chain |
| 初始访问 | Drive-by | 用户访问页面即加载代码 |
| 执行 | Browser RCE | WebKit / JavaScriptCore |
| 防御规避 | 环境筛选 | 仅攻击特定 iOS Safari |
| 防御规避 | JS 混淆 | Base64 / RC4 / Control Flow |
| 防御规避 | Hidden iframe | 隔离真正的 Exploit |
| 特权提升 | Sandbox Escape | SBX0 |
| 特权提升 | Kernel R/W | SBX1 |
| 防御规避 | PAC Bypass | PAC 相关原语 |
| 收集 | 数据访问 | Keychain / SMS / Photo / Wallet |
| C2 | 心跳 / 控制 | C2 配置下发 |
| 渗出 | 数据回传 | 加密数据传输 |
这里最值得注意的是:传统移动端安全思维经常把「安装恶意 App」视为攻击的起点,但在这种利用链中,Safari 本身已经成为 Initial Access Surface。
如果曾经用 iPhone 打开过 PolarNode,应该怎么处理
如果曾使用 iPhone 或 iPad 打开 event.polarnode.vip 或 polarnode.vip,并且访问时的系统处于受影响版本范围内,那么不能仅凭「手机目前没有异常」来判断设备安全。
完整 Browser-to-Kernel Exploit 成功后,本来就可能完全没有明显 UI 痕迹。
因此,更保守的响应策略是:
按照潜在完整设备失陷事件进行处置。
第一步:立即断网
优先关闭 Wi-Fi 和蜂窝网络,或者直接启用飞行模式。
目的不是清除恶意代码,而是尽快减少潜在 C2 通信继续发生的可能。
同时不应继续在该设备上登录交易所、打开钱包、修改密码、操作邮箱、使用密码管理器或处理企业敏感数据。
第二步:在可信设备上重新保护账号
所有凭据调整都应该使用另一台可信设备完成。
优先处理:
- Apple Account;
- 主邮箱;
- 密码管理器;
- 社交账号;
- 云盘;
- 交易所;
- 支付账户;
- 企业账号。
同时重新检查 MFA / 2FA 配置,因为当前样本中存在明确的 2fa 相关数据访问逻辑。
加密货币资产应该优先处理
如果受影响设备中使用过 imToken、TronLink 或其他软件钱包,最稳妥的策略不是简单修改钱包 App 密码,而是直接假设 Seed Phrase 或 Private Key 存在泄露风险。
建议按照以下顺序处理:
| 顺序 | 操作 |
|---|---|
| 1 | 在干净设备创建全新钱包 |
| 2 | 离线保存新的助记词 |
| 3 | 将资产转移至新钱包 |
| 4 | 撤销旧地址授权 |
| 5 | 永久弃用原钱包 |
钱包 App 的本地密码并不等于区块链资产的控制权。
一旦私钥泄露,修改 App 密码没有实际意义。
是否需要恢复出厂设置
对于 Browser RCE → Sandbox Escape → Kernel R/W → Process Injection 这一类攻击,没有可靠证据表明普通所谓「iOS 杀毒 App」能够完成彻底检测或清理。
如果设备确实处于攻击窗口并访问过相关页面,更可靠的处理方式是:
- 导出必要的照片、联系人等个人数据;
- 抹掉所有内容和设置;
- 更新到最新 iOS;
- 重新配置账户;
- 谨慎恢复必要数据。
不建议将「重启以后手机正常」作为安全依据。
一些可观察异常,但不能用来排除感染
可能出现的异常包括:
- 电池异常消耗;
- 手机持续发热;
- 网络流量异常;
- Apple Account 异地登录;
- 出现未知受信任设备;
- 钱包出现异常转账;
- 钱包授权记录异常;
- 系统出现未知描述文件。
但反过来说,没有这些症状并不能证明 Exploit 没有成功。
尤其是针对高价值目标设计的移动端攻击工具,本身就会尽量降低用户感知。
企业侧建议优先封锁这些指标
DNS、Proxy 和 Firewall 等位置可以优先封锁以下域名:
| 类型 | 指标 |
|---|---|
| 域名 | *.polarnode.vip |
| 域名 | *.wyincc.com |
| IP | 13.248.210.49 |
| IP | 166.117.225.238 |
| 端口 | TCP/36887 |
移动终端侧更应该关注行为
相比单纯封 IOC,更值得长期关注的是行为,例如:
- Safari / WebKit 异常崩溃;
- GPU Process 异常;
- 页面创建不可见 iframe;
- iframe 与主页面高频
postMessage; - 非业务第三方 JavaScript;
- Safari 访问极新域名后出现异常网络连接;
- 系统进程异常行为;
- 大量敏感数据库访问;
- 非预期进程访问 Keychain / SMS / AddressBook。
对于高风险人员设备,可以配合 MDM、自动系统更新、最低 iOS Build 限制和 Lockdown Mode 降低攻击成功概率。
IOC:网络指标
| 类型 | 值 | 作用 |
|---|---|---|
| 域名 | event.polarnode.vip | 诱饵落地页 |
| 域名 | polarnode.vip | 主域名 |
| 域名 | lk.wyincc.com | Exploit Loader / CDN |
| IP | 13.248.210.49 | C2 |
| IP | 166.117.225.238 | 关联端点 |
| 端口 | 36887/tcp | C2 出站特征 |
| URL | https://lk.wyincc.com/lk.js | 投递脚本 |
| URL | https://lk.wyincc.com/dist/sandbox.html | Exploit iframe |
| 路径 | /dist/chunks/ | 级联利用模块 |
IOC:文件哈希
| 文件 | SHA-256 |
|---|---|
lk.js | 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70 |
dist/sandbox.html | 953cfa9bf94304ad453eab706cd7cc92cde68eb6ea3c85652aa9040609e75f54 |
group.html | 99d0589e803ed000ea86d3ca143610b38af1dba0beb0cc32b9e9c2414a03a91b |
dist/chunks/runtime.js | a5ebcbd5c744865535dd75d8742c99bc06b548dc2606ac6f116843b54451f73b |
dist/chunks/runtime-legacy.js | afdb430bafc3c441ada98fe4a165fd1ad3a38ff5789517c5dd3f83a143706d53 |
dist/chunks/polyfill.js | f0409f0d1c134be43dcd697b4715cca64efa66e482d252744163f552050cd236 |
dist/chunks/framework.js | 78973b4d04cb6fee3c399937476347eca0aa9b99fa13596fe9dfaff829aba03b |
dist/chunks/common.js | 69e357f06ee87ea934b328c4e701d1d48dcfcef51352bb61c64ef89424c029d8 |
dist/chunks/sbx1_main.js | 55f7d9e99b8e2d4e0e193b2f0275501e6d9c1ebd29cadbea6a0da48a8587e3e0 |
dist/chunks/app.js | ab356a2bbdbb7f8e9327e10a2cf6d35ca0c4dbba06d982f559b00d13d31f3017 |
当前取证记录中 vendor.js 与 framework.js 存在缓存或文件命名重叠,因此相关哈希应结合实际样本内容判断,而不能单独依赖文件名。
IOC:字符串与行为特征
| 类型 | 特征 |
|---|---|
| Exploit | rce_offsets |
| 阶段名称 | SBX0 / SBX1 |
| 模板标记 | {{LPE_64BITE}} |
| 模块名 | sbx1_main.js |
| 配置项 | device_source=782391 |
| 通信 | heartbeat |
| Keychain | keychain-2.db / SecItemCopyMatching |
| 钱包 | global.wallet / im.token / tronlink |
这些指标相比单一域名更适合用于样本分析以及 YARA / EDR 侧的辅助检测。
这次攻击最值得关注的四个点
第一,用户几乎不需要参与后续攻击过程
PolarNode 使用 Next.js afterInteractive 自动加载 lk.wyincc.com/lk.js。
用户真正需要做的事情只有:
打开链接。
后续 Exploit 不依赖安装恶意 App,也不需要继续点击页面。
第二,它针对的是相对较新的 iOS 版本
样本直接包含 iOS 18.6、18.6.1 和 18.6.2 三套系统 Build 的适配,并不是传统意义上只攻击多年未更新的老旧 iPhone。
这也再次说明:
「系统版本比较新」和「系统已经安装最新安全修复」并不是同一个概念。
第三,Exploit 与最终犯罪目标高度解耦
利用框架负责完成 RCE、Sandbox Escape 和 Kernel Exploitation,最终 app.js 则专门负责 Keychain、SMS、Photo、Contact 和 Wallet 数据采集。
这种模块化设计意味着攻击者可以较容易地替换诱饵、C2 和 Payload,同时继续复用 Exploit Framework。
第四,高端移动 Exploit 正在向普通黑产扩散
DarkSword 一类 Full Chain 最初更多出现在 Commercial Surveillance、APT 和 Targeted Espionage 场景。
而 PolarNode 展示的是另一条演化路线:
高价值 Exploit → 公开 / 泄露 / 商品化 → 犯罪团伙重新封装 → 面向普通用户投递 → 直接盗取加密资产。
这可能比某一个具体恶意域名本身更加值得关注。
最后
PolarNode 看起来只是一个常见的「免费 VPS」活动,但静态拆解后,背后的实际攻击路径是:
免费 VPS 诱饵 → 邀请裂变 → 技术 / Crypto 人群筛选 → Next.js 自动加载 → iOS Safari Exploit → JavaScriptCore RCE → GPU Sandbox Escape → Kernel R/W → PAC Bypass → Payload Injection → Keychain / 2FA / Wallet 窃取 → C2 回传。
其中,rce_offsets 对 iOS 18.6、18.6.1 和 18.6.2 的大规模设备适配,说明这并不是一段简单拼接出来的漏洞 PoC。
而 app.js 中针对 Keychain、相册、短信、通讯录以及 imToken / TronLink 的代码,则直接揭示了最终目的:
获取能够转换成账号控制权和真实经济收益的数据。
从更大的角度看,这次活动再次证明了一件事:
对于攻击者而言,只要仍然存在大量没有及时更新系统的设备,已经公开的 n-day Exploit 就依然具有实际价值。
而当过去只用于高价值定向攻击的 iOS Full Chain 被重新打包并进入网络犯罪市场以后,「我没有安装任何东西」也不再能够作为移动设备安全的充分依据。
本文所有结论均基于公开可访问页面以及相关样本的被动静态取证完成,未对漏洞利用链进行主动触发。IOC 具有明显时效性,攻击者可以随时替换域名、IP、CDN 路径与文件哈希,因此实际防御仍应结合系统版本、网络行为和终端异常进行综合判断。




评论 (0)