一封退货邮件的陷阱：“开箱视频”背后的 WPS、隐藏 DLL 与恶意加载链

AI 辅助声明｜AI agent coding 辅助创作

Codex 辅助编写取证脚本、分析静态与隔离运行记录，并参与本文整理和写作。

安全警告：不要点击文中的可疑地址、下载样本或运行其中的程序。

我有相关技术经验，日常使用 Linux 桌面，才另外准备隔离环境分析这封邮件并写下本文。

样本执行只发生在断网虚拟机里的 Wine 中，宿主个人目录和账号会话没有共享进去。

Linux 和 Wine 都不提供“随便运行 Windows 恶意程序也安全”的保证，虚拟机也有剩余风险，请勿照着尝试。

AI 生成的封面插画：以查看售后视频为由，引向 EXE 与 DLL 加载链；不是取证截图。

一封声称“商品损坏，想申请退货”的邮件，最后交来的是一个 Windows 程序包。

最显眼的文件名里写着 mp4，内部身份却是 WPS PDF；它启动时还会加载旁边的 DLL，继续解包、运行 Python，并尝试装入 .NET 代码。

这就是我在 2026 年 11 月 4 日收到的那封邮件。

对方没有索要密码，也没有催我付款，而是请我先看开箱视频和照片，再处理售后。

对于每天处理客户邮件的人，这个请求很像正常工作的一部分。

沿着它给出的链接往下看，危险的转折发生在“查看材料”被换成“启动程序”的时候。

售后故事给外链下载找好了理由

邮件标题是「有關產品無法使用的退貨查詢」。

发件人显示为「張慧敏」，声称刚收到的商品内部严重损坏、无法使用，已经保留开箱视频和照片，希望安排退货、换货或退款。

材料没有附在邮件里，因为“文件太大”，需要打开外链查看。

原始收件画面：退货诉求与“文件太大，请查看链接”连在一起。

这封信借用了售后处理中很自然的一步：先看证据，再决定怎么解决问题。

它缺少订单号和商品名称，却给了收件人一件可以立刻做的事，也就是打开链接。

发件地址里的 AppSheet 属于正规服务，但地址本身无法证明这是一位真实客户。

AppSheet 官方文档说明，自动邮件的主题、正文和发件人显示名称可以配置。

使用正规平台发送邮件，与邮件中的售后故事真实，是两件需要分别核对的事。

我没有取得这封信的完整原始认证头，因此不判断用于核验邮件来源的 SPF、DKIM、DMARC 认证是否通过。

Google 短链接把浏览器带到了第三方下载站

邮件里的 share.google 确实是 Google 使用的短链接域名。

Google 官方中文说明提到，Google 应用分享网页时会生成 share.google 或 search.app 链接。

这能解释入口为什么看起来熟悉，最终目的地仍要沿跳转记录检查。

这次短链经过 Google 的几次重定向后，进入了 filehub.freshpartners[.]co.nz 的下载路径。

下文可疑地址里的 [.] 表示点号，hxxps 表示已去活化的协议名，避免文章形成可直接点击的样本入口。

1
hxxps://share[.]google/psgMaz996t9HspoPs
2
  → www.google.com/share.google?q=…                 HTTP 302
3
  → www.google.com.hk/url?…                         HTTP 302
4
  → www.google.com.hk/share.google?q=…              HTTP 301
5
  → filehub.freshpartners[.]co.nz/dl/
6
      Complete_Item_Assessment_mp4/ca50…b467?…      HTTP 302

301 和 302 是服务器要求浏览器转到其他地址的响应，这些中间节点没有各自呈现一张网页。

同一台 Linux，两次会话得到了不同内容

我先用 Linux 浏览器的默认客户端标识访问短链，最后看到的是微软 OneDrive 产品介绍页。

它没有展示开箱视频，也没有要求我更换操作系统。

第一份浏览器结果：真实的 OneDrive 产品页，邮件里的售后材料并未出现。

另一次会话把请求中的客户端标识改成 Windows Chrome，下载站就交付了 ZIP 附件，没有出现视频播放器。

两次浏览器实际都运行在 Linux 上，这里的 Windows 只是请求头中的标识。

另一份浏览器结果：Chrome 已记录下载；自动化保存时使用内部标识，服务器给出的文件名见下方响应头。

ZIP 大小是 138,900,867 字节，约 132.47 MiB，文件名仍在强调 mp4。

1
HTTP/2 200
2
Content-Type: application/octet-stream
3
Content-Length: 138900867
4
Content-Disposition: attachment; filename="Complete_Item_Assessment_mp4_838a86d1.zip"
5
Cache-Control: no-store, no-cache, must-revalidate, max-age=0

这两份结果能证明下载站返回了不同内容，尚不能证明它只按操作系统筛选。

分支是两次会话的记录，不是对服务器筛选算法的还原。

文件名带着 mp4，扩展名却是 exe

我先读取压缩包目录、提取字节分析，没有在日常桌面双击程序。

包内共有 791 个条目，其中 742 个文件、49 个目录；与下载名对应的目录顶层，只有一个 EXE、一个 DLL 和一个目录。

EXE 的完整名称是 Complete_Item_Assessment_mp4.exe，表中简写为 …_mp4.exe。

隐藏与系统属性来自 ZIP 中央目录的实际记录。

如果解压工具保留属性，Windows 又按相关设置隐藏这些文件，收件人最容易看见的就会是那个名称带着 mp4 的 EXE。

读这个文件名时，应看最后的 .exe，而不是中间的 _mp4。

扩展名也可以被伪装，真实格式还要结合文件头和内容核对；这里已经确认交付的是 Windows 程序。

微软的扩展名说明也把 .exe 与 .mp4 分别列为可执行程序与视频类型。

到这一步，普通收件人已经有充分理由停下：售后照片和视频，没有解释为什么需要运行 EXE。

真实 HTTP 与文件分析输出的排版摘录，方便对照文件名、大小和 DLL 依赖；不是下载站页面。

这个 EXE 内部仍然叫 WPS PDF

读取程序内部字段后，可以看到 WPS PDF、WPS Office 和原始文件名 wpspdf.exe。

它保留了办公软件的身份，外部文件名却被改成了“商品评估 mp4”。

更关键的是，EXE 的导入表明确依赖同目录里的 krpt.dll。

导入表记录程序启动时需要装入的外部模块，这个依赖把 EXE 与旁边的 DLL 接到了一起。

1
DLL: krpt.dll
2
Imported symbol: ?_force_link_krpt@@YGXXZ
3
Import Address Table RVA: 0x00097260

DLL 是程序调用的功能模块，装入进程时可以执行初始化代码。

将一个现成 EXE 与恶意 DLL 放在它会加载的位置，借 EXE 启动 DLL，通常称为 DLL side-loading，DLL 侧加载。

微软的 DLL 安全说明指出，攻击者控制 DLL 搜索位置时，程序可能加载非预期的库，并以宿主进程的权限执行其代码。

具体搜索顺序受应用和加载方式影响；这个样本除了有明确导入依赖，后面的运行日志也记录到了该 DLL 的实际装载。

隐藏 DLL 把“看文档”接成了多层执行

沿着 DLL 的初始化路径分析，程序打开了 x 目录中的一个伪装 PDF，解码其中的数据，再把恢复出的命令交给进程创建函数。

本文使用 REA（Reverse Engineer Anything）接口读取文件结构，并通过 Hopper 查看原生代码的反汇编与伪代码。

反汇编把机器指令转换成可读指令，反编译尝试还原接近高级语言的表达式，二者都不等于取得了作者的原始源码。

这条路径解释了为什么只看 WPS 的名称会漏掉问题：用户启动的是 EXE，后续动作已经转入 DLL 的初始化代码。

类框按实际文件划分职责，用于讲解组件关系，并非声称这些二进制定义了图中的同名类。

小 PDF 装命令，PNG 负责解压，更新程序其实是 Python

DLL 读取的文件路径是 x\수박_유튜브시청기록_2015-12-10.pdf，总共只有 1379 字节，没有 PDF 文件头。

它使用 RC4 流加密保存命令：文件前段是密文，后段是密钥，最后四字节给出密钥长度。

只对字节执行同样的解码运算，就能恢复连贯的 UTF-16 命令文本，不需要运行恢复出的命令。

命令先进入 x 目录尝试打开 document.pdf，随后调用后缀为 PNG 的程序，解开 DAT 归档，再启动解包出来的 MicrosoftEdgeUpdate.exe。

逐一核对格式后，PNG 外观的文件被识别为 RAR 解压程序，DAT 是加密归档，document.pdf 则是 Word 容器。

名字像浏览器更新组件的 MicrosoftEdgeUpdate.exe，内部身份是 Python 解释器；它随后要解释的另一个 PDF 外观文件，也是一份混淆脚本。

文件内部的版本与厂商字段是识别线索，不代表已经逐个验证原厂完整性或有效签名。

MicrosoftEdgeUpdate.exe 旁边还有 python314.dll、python314.zip 和 python314._pth，与Python 官方中文文档描述的嵌入式发行结构相符。

在这份投递包里，解释器被改成浏览器更新组件的名字，又被用来解释另一个 PDF 外观文件里的代码。

按真实文件字节、可信解压器与版本资源整理的证据摘录，不含口令和完整执行参数。

CLR 是执行 .NET 代码的公共语言运行时，Python 在这里又承担了调用 CLR、装入下一阶段程序的宿主角色。

“载荷”指这份等待执行的下一阶段代码，不表示它的完整功能已经被还原。

这份 .NET 文件的字节已完整恢复，但元数据存在重复行和无效索引，REA 只完成部分读取；图里的 partial 指分析覆盖范围，不是只恢复了一部分文件。

这张图汇总静态恢复出的文件关系与脚本控制流，运行到哪一步，由后面的日志核对。

脚本还准备在下次登录继续运行

恢复出的 Python 源码包含大量算术、随机名称和间接表达式。

我只对白名单内的常量和字节运算做折叠，把源码当作数据整理，再用隔离运行记录核对结果。

整理后的逻辑尝试创建计划任务，并从两处用户登录入口调用它。

微软对 Run 键的说明确认了它在用户登录时启动程序的用途。

这种为后续登录留下启动入口的做法称为持久化。

它让风险超过了一次误打开：关闭眼前窗口，并不一定移除了重新启动代码的入口。

脚本另有针对扫描接口的内存修改逻辑，现有记录没有确认其在实验中生效，本文不展示修改字节或绕过步骤。

原生逆向细节：DLL 入口、API 哈希与进程创建

导出函数是空的，不代表 DLL 没有动作

用 REA 接入 Hopper 对 krpt.dll 做反汇编和关键函数反编译后，一个容易误判的地方出现了：大量导出落到 0x100179e0，那里只是一个返回用的空桩。

如果只看这个导出，很容易以为 DLL 什么也没做。

但 DLL 还有加载入口。

这个样本的入口位于 0x1001c728，经运行库初始化包装后进入 0x10001000；后者在进程附加条件下进入文件读取和后续处理路径。

“进程附加”指 DLL 被装入进程时收到的初始化通知，不需要用户再单独点击一次 DLL。

地址或位置	静态分析看到的行为
0x1001c728	PE 入口，转入初始化包装
0x1001c5ef	运行库包装中存在到 0x10001000 的调用
0x100167c7	比较初始化原因是否为 1，即进程附加
0x1001687a	调用 0x10019280，准备动态解析的 API 地址
0x10016959、0x10016ca7	经解析后的指针调用 CreateFileW
0x100172ca	调用 ReadFile，读取数据到缓冲区
0x100176aa	调用 0x10018160，含 RC4 式状态表初始化、交换和异或处理
0x1001778b	将同一缓冲区传入 0x100179f0
0x10018100	在 0x100179f0 内，间接调用进程创建 API

这些是按 PE 首选基址整理的静态地址和调用关系。

Wine 观察中，krpt.dll 实际被映射到 0x7B590000，不能把表里的静态地址原样当成运行时断点地址。

为什么导入表里找不到完整行为

krpt.dll 的普通导入表主要是 KERNEL32.dll 的运行库相关函数，没有直接列出上面所有关键 API。

它另外实现了按哈希值查找函数地址的逻辑。

简单说，程序不在这个位置写出容易搜索的 CreateProcessW 字符串，而是保存一个数字，运行时再根据函数名称计算结果、寻找对应地址。

我把反汇编中的哈希运算单独转写成只处理字符串的 JavaScript，核对候选 API 名称；这不需要执行样本。

哈希常量	对应的候选函数名	DLL 保存地址
0xc563eb80	CreateFileW	0x1004d2a0
0x35d5ea3a	CloseHandle	0x1004d29c
0xacb08688	ReadFile	0x1004d298
0xa1059b95	GetFileSizeEx	0x1004d294
0x628857b4	CreateProcessW	0x1004d290

哈希可能碰撞，所以还要核对调用参数，不能凭一个数字直接给任意间接调用命名。

最后一项同时吻合了进程创建函数的十个参数、启动信息结构和进程信息结构，支持把这个调用识别为 CreateProcessW。

下面是把关键调用整理成易读形式后的节选，变量名是为讲解重命名的，省略了大量常量运算和包装，不是恢复出的原始 C 源码，也不是可直接编译的完整程序。

1
// 0x10019280 中的解析结果写入 0x1004d290。
2
// 0x100179f0 的调用处使用这个函数指针。
3
STARTUPINFOW startup = {0};
4
startup.cb = 0x44;                  // 32 位 STARTUPINFOW 的大小
5
PROCESS_INFORMATION process = {0};
6

7
resolved_CreateProcessW(
8
    NULL,                          // 由命令行中的首个项目决定启动目标
9
    decoded_buffer,                // 上游读取、处理后传来的缓冲区
10
    NULL, NULL, FALSE,
11
    0x08000000,                    // CREATE_NO_WINDOW
12
    NULL, NULL,
13
    &startup, &process
14
);

CreateProcessW 的官方定义是创建进程和主线程。

其中 0x08000000 对应 CREATE_NO_WINDOW，对于控制台程序，可以不创建控制台窗口；它不等于对任何类型程序都能“完全隐身”。

这个链条已经明显超出了“显示商品照片”的用途：旁加载的 DLL 在读取数据、进行解密式处理，并准备以处理后的内容启动另一个进程。

继续恢复初始化代码构造的路径后，缓冲区的来源也明确了：它来自 x 目录里一个伪装成 PDF 的小文件，解码后是一段 cmd.exe 命令。

REA 静态反编译输出节选：哈希解析写入函数指针，后续以 0x08000000 标志调用；变量保留反编译器命名。

图表示静态代码安排的顺序；后文用隔离 Wine 的进程和文件记录核对它的运行结果。

断网运行核对：后台解包、启动与注册表写入确实发生了

静态分析指出了执行方向，运行记录则用来回答其中哪些动作真的发生。

我把原始投递包放进断网 KVM 虚拟机里的 Wine 观察，启动前核对 EXE、DLL 的哈希，没有修改载荷或修补它的调用逻辑。

Wine 提供 Windows 兼容环境，但新建一个 Wine prefix 并不能把未知程序安全地关住。

prefix 是虚拟 Windows 目录、注册表和配置的一组文件；Wine 仍可能把文件操作映射到 Linux 路径，删除 Z: 盘符也不能单独阻断这种访问能力。

因此，隔离边界放在虚拟机及外层限制上。

宿主个人目录、账号会话、图形与剪贴板均未共享给样本。

第一轮已经走到了 Python 和持久化写入

原始 EXE 启动后，Wine 加载了 krpt.dll，随后出现 cmd.exe、伪装解压器和改名的 Python 程序。

document.pdf 没能打开，日志中 winebrowser 报告找不到合适应用，后续解包与 Python 启动仍然继续。

native 在这些 Wine 日志里表示按外部 Windows 模块加载，与 Wine 的 builtin 内建实现相对，不表示这是原生 Windows 上的测试。

stub 表示相关接口在该环境中是桩实现，所以“调用过任务接口”和“下次登录一定能启动”之间还缺一段证据。

来自客体运行记录的排版摘录；持久化值写入、任务接口的 stub 和 CLR 错误分别保留。

缺少 Wine Mono 是实验环境的兼容性终点，不能据此推断它在 Windows 上也会停住。

Python 脚本虽然包含虚拟机检查函数，但对应的主入口提前退出条件经常量折叠为 if 0，现有记录也不支持把这次停止归因于反虚拟机检测。

补齐运行时后，Mono 与微软 CLR 得到不同结果

我又准备了 Wine Mono 和微软 .NET Framework 4.8 两种环境，先用无害的 x86 探针核对运行时，再观察原始投递链。

Wine Mono 是 .NET Framework 的替代实现，与微软原版 CLR 需要分开看待。

Wine Mono 的版本与安装包哈希可对照 Wine 10.0 安装源码，微软运行时来自 .NET Framework 4.8 官方下载页。

Mono 中确认执行的是初始化路径；微软 CLR 中确认的是模块加载和该进程的域名解析请求，两者都不足以宣布最终功能完整运行。

两种运行时的结果并列展示；DNS 报文来自断网客体记录。

1
BENIGN_CLR_OK Version=4.0.30319.42000 PointerBytes=4 System=v4.0.30319
2
BENIGN_REFLECTION_OK mscorlib

1
EXCEPTION handling: System.Reflection.TargetParameterCountException
2
ENTER:c <Module>:.cctor
3
ENTER:c <Module>{…}:.cctor
4
EXCEPTION handling: System.InvalidProgramException: Invalid IL code
5
  ... RMFVJx67UD (bool&): IL_0229: stloc 3
6
EXCEPTION handling: System.TypeInitializationException
7
EXCEPTION handling: System.Reflection.TargetInvocationException

实验结束后，Wine 进程停止，客体关机，QEMU 退出，宿主上用于检查文件变化的哨兵文件哈希保持不变。

域名出现在日志里，但记录停在本地 DNS

微软 CLR 那轮观察中，原链重新启动的 Python 进程向客体本地解析器 127.0.0.53:53 请求了 tea[.]vexexo[.]com 的 A 和 AAAA 记录，分别用于寻找 IPv4 和 IPv6 地址。

这些请求都没有得到地址答案。

回复码是 5，按 RFC 1035表示 REFUSED。

拒绝来自客体本地 DNS 解析器，样本没有因此成功联系上域名对应的外部服务器。

DNS 记录定位了待解析的名字，没有给出上层协议、请求路径或传输内容。

它是这份样本的一条候选通信线索，尚不能被叫作已经确认的上传地址。

另行查询的公开记录与第三方信誉

样本观察结束后，我另行查询了公共 DNS、域名登记与路由信息。

以下是 2026 年 11 月 4 日晚取得的公开快照，与样本在客体里产生的流量是两组记录，之后也可能变化。

记录可以分别对照 Google 公共 DNS、Verisign 域名登记、RIPE 地址登记及路由信息；这些是公开信息服务的查询入口。

同一天晚上的 isMalicious 域名报告还把这个名字标为 Medium Risk（中等风险）。

2026 年 11 月 4 日查询时的原始页面截图，评级与收录状态可能变化。

这份聚合记录表明该域名已经出现在第三方威胁情报中，多个名单也可能共享上游数据，不能把 7 个来源直接当成 7 次独立样本分析。

其中 C2 指 Command and Control，即恶意程序与控制端之间的指令和通信机制。

名单标签提供了调查方向，不能代替这份样本的通信协议还原，更不证明实验中发生了数据上传。

已确认的危险，已经足以拒绝这个包

这份包将售后图片、视频的查看请求，变成了改名 EXE、DLL 侧加载、解包、Python 和内存载荷加载的执行链。

运行记录还确认了两处登录启动值写入，危害判断不必等到恶意软件家族有了名字才成立。

DLL 侧加载通常先以宿主进程的权限执行，不会因此自动取得管理员权限。

普通用户权限下的代码仍可能访问该用户可读的文档和敏感数据，具体范围受系统权限与应用保护约束。

这是未知程序执行带来的风险范围，当前记录没有证明这份样本已经完成了上述窃取。

实验中的注册表与 Public 目录属于客体 Wine 环境，也不表示日常 Linux 宿主已被感染。

已有调查使用了相同的 WPS 宿主文件

我取得的 WPS EXE，还能与 OSArmor 在 2026 年 10 月 23 日发表的原始调查对应上：两份 EXE 的 SHA-256 完全相同，DLL 的哈希和大小则不同。

该报告中的邮件写成日文，同样以商品损坏为由，通过 AppSheet 和 Google 短链投递改名 WPS EXE 与 krpt.dll。

文件哈希相同支持“复用了相同宿主文件”的判断，相似包装不能直接确定同一个攻击者，也不能把另一份 DLL 的行为套在本样本上。

1
ZIP（138900867 字节）
2
28e53894076225e468fd237bcfb1cdd8d683448c9757770d8cfdd7a948ae13b5
3

4
Complete_Item_Assessment_mp4.exe（1321728 字节）
5
c73e3b98b5f631669fb3d4b114e98ad55d2b015e2c55003c265e0b75e0c31d9e
6

7
krpt.dll（126144000 字节）
8
8f7eb86566d45ecfa85a7dd46c72b8db55a24a7a0cc7882fe5929d8506664bd4
9

10
从原包恢复出的 .NET 载荷（433152 字节）
11
5e9488d34be24163c971679f5d5d5d3a32c7ae94978c5d01dcbd8793fd6b0fdd

收到类似邮件，先核对业务，再核对文件用途

普通收件人不需要会反编译，也能在下载前或启动前识别这条链上的问题。

先回到自己已有的订单系统、工单和客户联系方式，确认是否真有这笔业务，再决定如何接收材料。

在 Outlook 中，可以选中可疑邮件，再通过“报告 → 报告钓鱼”提交，具体入口见微软的 Outlook 中文帮助。

报告钓鱼并不等于阻止发件人继续发信，是否加入阻止列表需要另行处理。

已运行程序时，处置重点转向隔离和排查

是否执行过文件、是否提交过凭据，会改变下一步处理方式。

如果 Windows 设备已经运行过未知程序，可以参考微软 Defender 脱机扫描的中文说明，了解在常规 Windows 环境之外进行扫描的方法。

一次未检出不能代替完整排查，也不能证明程序留下的登录启动项已经清除。

如果还向可疑页面提交过 Outlook 或 Microsoft 账户凭据，账户与设备要分别处理。

在受影响电脑上更改密码之前，应先排查其中的恶意软件；也可以使用另一台干净设备处理账户。

微软的账户恢复中文帮助列出了扫描设备、更改或重置密码，以及检查连接账户、邮件转发和自动答复设置的步骤。

这封退货邮件没有把危险写在第一句话里。

它让“帮客户看一下损坏情况”成为打开外链的理由，又把本该直接查看的材料换成了程序包。

我能从这份样本确认到后台加载、持久化写入和一次次被本地拒绝的域名解析，最终载荷的完整行为仍然未知。

对真正处理售后的人来说，可以更早停在那个文件名面前：看开箱视频，为什么需要运行 .exe？