企业官网建设流程全解析

Junction点劫持揭秘：RedSun如何用重解析点把Defender的文件写入重定向到System32

【免费下载链接】RedSunThe Red Sun vulnerability repository项目地址: https://gitcode.com/gh_mirrors/re/RedSun

RedSun 是一个专门研究Junction点劫持（Junction Point Hijack）的 Windows 提权 PoC 项目：它利用 Windows Defender 处理"云标签"文件时的一个怪异行为，配合 NTFS 重解析点（Junction）把杀毒软件自己的文件写入操作重定向到C:\Windows\System32，最终让普通用户程序以 System 身份运行。整个过程不用 UAC 弹窗、不用已公开的提权漏洞，堪称对"文件路径解析"这一底层机制的精准利用。

一句话说清 RedSun 在做什么

杀毒软件以为自己在"修复/还原"一个恶意文件，结果写入路径被攻击者提前埋下的 Junction 点劫持，文件最终落在了 System32 里。

用作者的话说（见 README.md）：

当 Windows Defender 发现一个恶意文件带有云标签时，这个本应负责保护的杀毒软件会认为"把它写回原位置"是个好主意……PoC 利用这个行为覆盖系统文件，从而获得管理员权限。

也就是说，Defender 不是删掉了恶意文件，而是把它重新写了一遍——而"原位置"早已被攻击者用重解析点改道。

漏洞背景：云文件让 Defender 行为"反转"

要理解这个攻击，先了解两个 Windows 机制：

• 云文件占位符（Cloud Placeholder）：Windows 10 之后，云盘/同步盘上的文件可以只保存一个"占位符"，文件内容不落地。Defender 遇到这类带"云标签"的文件时，处置逻辑会出现偏差——它不删除，而是选择将文件重新写回原路径。
• Junction（目录联接/重解析点）：NTFS 允许在目录上挂一个"快捷入口"，把该目录下的所有路径访问悄悄指向另一个位置。挂在目录上的这种重解析点就是 Junction，对上层应用完全透明。

把两者组合起来，攻击链就成立了：让 Defender 主动去写一个路径 → 这个路径经过 Junction 被重定向 → 写进去的内容由攻击者控制。

攻击原理四步走

PoC 的完整执行效果如下：主进程输出 "The red sun shall prevail." 后，新弹出的命令行中whoami显示nt authority\system——这就是 Junction点劫持成功的直接证据。

第1步：伪造恶意文件，主动触发 Defender 响应

PoC 在%TEMP%下创建临时工作目录，写入一个 EICAR 测试病毒文件，命名为TieringEngineService.exe（见 RedSun.cpp）。EICAR 是业界通用的安全测试字符串，Defender 的实时保护会立即对其做出响应。

第2步：等待并锁定 Defender 的"影子"动作

Defender 处置文件时会创建卷影副本（VSS）。PoC 启动了一个后台线程持续轮询对象管理器\Device命名空间，捕捉新出现的HarddiskVolumeShadowCopy设备（ShadowCopyFinderThread，见 RedSun.cpp）。

一旦捕获到影子副本，PoC 会对副本中的目标文件请求Batch Oplock（批量操作锁）。Oplock 是文件系统级别的"写入通知"机制：谁接下来要动这个文件，谁就必须先向 PoC 发信号——这相当于在 Defender 动手的瞬间安上了一个"绊线"。

第3步：给恶意文件打上"云标签"

这是整个攻击最"阴"的一环。PoC 通过 Windows 云文件 API（CfApi）注册同步根目录、连接并创建带MARK_IN_SYNC标志的云占位符（DoCloudStuff，见 RedSun.cpp），为恶意文件加上"云标签"。

打上标签后，Defender 对该文件的处置策略就从"删除"变成了"写回原位置"——这正是漏洞的触发条件。

第4步：Junction 重解析点劫持写入路径

在 Oplock"绊线"被 Defender 触碰后，PoC 开始收网：

1. 先把工作目录改名腾位，重新创建同路径的空目录；
2. 在该目录上通过FSCTL_SET_REPARSE_POINT设置一个IO_REPARSE_TAG_MOUNT_POINT类型的重解析点，目标是\??\C:\Windows\System32（见 RedSun.cpp）；
3. 此时 Defender 执行"写回原位置"，路径解析被 Junction 劫持，写入流量全部落入 System32。

随后 PoC 把自己的可执行文件拷贝到C:\Windows\System32\TieringEngineService.exe并启动它（CopyFile+ COM 实例化，见 RedSun.cpp）。由于进程直接从系统可信目录 System32 启动，Windows 会赋予其更高的信任级别，最终提权为NT AUTHORITY\SYSTEM。

⚠️ 需要强调：PoC 全程依赖 Defender 主动写入文件这一"自爆"行为，如果实时保护关闭（代码里会提示 "PoC timed out, is real time protection enabled ?"），攻击链会在第 2 步超时失败。

这个 PoC 给安全行业的三点启示

1. 处置动作本身也可能成为攻击面：传统思路只审计"攻击者能写哪里"，而这个案例里，写入方是杀毒软件自己。任何自动化的文件修复/还原逻辑，都应校验路径解析结果与预期一致。
2. 路径解析要防重解析点劫持：关键系统目录（如 System32）的写入/读取逻辑，应显式排除经过 Junction 等重解析点的间接路径（例如使用带FILE_OPEN_REPARSE_POINT语义的直查接口并校验目标卷）。
3. 对安全研究者的警示：云同步、VSS、Oplock 等"正常特性"的组合可能产生意料之外的安全后果，安全产品在设计处置策略时需要覆盖这类组合场景。

获取与阅读建议

项目代码非常精简，只有两个核心文件，非常适合想学习 Windows 文件系统机制与提权原理的读者逐行研读：

• RedSun.cpp：完整 PoC 实现（约 780 行，注释极少，挑战十足）
• README.md：项目背景与行为说明
• LICENSE：MIT 许可

git clone https://gitcode.com/gh_mirrors/re/RedSun

📌阅读路线建议：先从main()入手理解整体流程（创建管道 → 写 EICAR → 等 Defender → 打云标签 → 埋 Junction → 收割提权），再回头精读ShadowCopyFinderThread的 VSS 轮询与DoCloudStuff的云占位符构造，两条线程如何通过全局事件gevent精确同步，是这份代码最精彩的部分。

【免费下载链接】RedSunThe Red Sun vulnerability repository项目地址: https://gitcode.com/gh_mirrors/re/RedSun