RuntimeBroker.exe 是 Windows 操作系统中的一个系统进程,它负责管理 Metro 应用程序(现在称为 Universal Windows Platform 应用程序)的权限和沙盒环境。该进程通常在用户登录后启动,并且对于每个用户会话都会有一个实例在运行。
RuntimeBroker.exe 完整解构
路径:
C:\Windows\System32\RuntimeBroker.exe角色定位:AppModel 运行时代理 / UWP/AppContainer 沙箱协调器。
核心职能:接收 DCOM/LRPC 激活请求,读取 Appx 包清单,构造 AppContainer 安全令牌、创建容器隔离环境,调用
CreateProcessAsUser孵化 UWP 系统应用(ShellExperienceHost、StartMenuExperienceHost 等);同时负责 UWP 运行时的权限代理、能力(Capability)校验、资源访问中转。运行身份:当前交互式登录用户令牌(非 SYSTEM);仅具备代理编排能力,不永久提权。
一、底层原理
- AppContainer 安全模型编排 AppContainer 是 SID + 强制完整性(Mandatory Integrity Control)的隔离模型。RuntimeBroker 读取 AppX 包清单(
AppxManifest.xml),解析包声明的capabilities(internetClient、picturesLibrary 等),向 LSASS 请求派生受限访问令牌,附加 AppContainer SID(S-1-15-2-xxxx),设置低完整性级别,剥离管理员 SID 与高权限特权。 - COM/LRPC 激活调度 对外暴露
IAppxBroker本地 COM 接口;由 DcomLaunch 接收 AppID 激活请求,转发至 RuntimeBroker。仅本地 LRPC,不开放远程 DCOM。
流程:DcomLaunch 发现目标 AppID 标记为 AppContainer 类型 → 调用 RuntimeBroker COM 接口,请求创建容器环境并启动进程。
- 隔离环境挂载 创建 AppContainer 内核配置文件对象,自动挂载:
- 独立内核对象命名空间(容器进程默认无法访问全局互斥体 / 事件)
- AppContainer 虚拟化注册表(HKCU 分支隔离,写时虚拟化)
- 容器私有存储目录
%LOCALAPPDATA%\Packages\<包名>\
- 运行时资源代理(Broker 代理模型) AppContainer 进程是低 IL,无法直接访问多数系统资源。当 UWP 进程需要访问文件、注册表、设备、相机时,会调用 RuntimeBroker 的 COM 接口,由 RuntimeBroker 使用用户主令牌代为执行访问,完成权限中转。
- 进程生命周期代理 RuntimeBroker 作为 UWP AppContainer 进程的父进程;进程创建完成后,RuntimeBroker 不再介入 UI 业务逻辑,仅保留代理通道用于资源访问。RuntimeBroker 可同时孵化多个 UWP 子进程。
二、依赖文件 & 依赖关系
用户态模块
| 文件 | 作用 |
|---|---|
| RuntimeBroker.exe | 主程序入口,IAppxBroker COM 接口实现 |
| combase.dll / ole32.dll | COM/LRPC 通信,接收 DcomLaunch 激活请求 |
| rpcrt4.dll | LRPC 本地 RPC 传输层 |
| userenv.dll | AppContainer Profile 管理,CreateAppContainerProfile API |
| advapi32.dll | 令牌操作、LSA 客户端、CreateProcessAsUser |
| sechost.dll | LSA RPC 客户端,与 lsass.exe 通信 |
| ntdll.dll | Nt 原生 API,内核调用入口 |
| crypt32.dll | Appx 包签名校验 |
| appmodel.dll | AppX 包元数据、清单解析、Package 查询 |
| winrt.dll | WinRT 运行时基础库 |
内核与系统服务依赖
lsass.exe(本地安全机构):强依赖,令牌派生、SID 生成、安全策略校验。ntoskrnl.exe:AppContainer 内核对象、令牌对象、MIC 强制完整性、对象命名空间管理。DcomLaunch(svchost):DCOM 本地激活,发起 IAppxBroker 调用。RpcSs:LRPC 基础 RPC 服务。win32k.sys:窗口站、桌面会话隔离,UWP 窗口渲染基础。
注册表依赖
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository:已注册 Appx 包元数据HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppContainer:AppContainer 全局策略HKCU\Software\Microsoft\Windows\CurrentVersion\AppContainer:用户侧容器配置文件HKCR\AppID\:UWP 系统 App(ShellExperienceHost 等)DCOM AppID 注册项
存储路径
C:\Program Files\WindowsApps\:第三方 UWP 应用包C:\Windows\SystemApps\:系统内置 AppX 包(ShellExperienceHost 等)%LOCALAPPDATA%\Packages\:AppContainer 私有存储目录
三、调用链 & 逻辑链路(以 ShellExperienceHost 启动为例)
用户交互:点击任务栏时钟 → explorer.exe捕获鼠标事件
↓ LRPC(DCOM)
DcomLaunch(svchost)接收AppID激活请求
↓ DcomLaunch识别目标AppID为AppContainer类型
↓ LRPC调用 RuntimeBroker::IAppxBroker::ActivateApplication
RuntimeBroker启动(未运行时),加载appmodel.dll读取AppxManifest
↓
1. 解析包全名、AppContainer名称、capability能力列表
2. DeriveAppContainerSidFromAppContainerName() 生成S-1-15-2-xxxx容器SID
↓ 调用LSASS(lsass.exe)
3. DuplicateTokenEx:基于当前交互式用户主令牌派生受限令牌
- 添加AppContainer SID到TokenGroups
- 设置强制完整性:LOW(低完整性)
- 裁剪SID、移除高危特权
- 注入Capability SID(如internetClient)
↓ userenv.dll::CreateAppContainerProfile
4. 创建AppContainer内核对象,挂载独立命名空间、虚拟化注册表
↓
5. CreateProcessAsUserW(受限AppContainer令牌, ShellExperienceHost.exe)
内核绑定令牌、挂载容器环境,启动ShellExperienceHost
↓
6. 进程启动成功,COM对象注册,返回OBJREF/OBJREF+OBJREF(OBJREF是COM对象引用)给DcomLaunch
↓
DcomLaunch回传OBJREF给explorer.exe
↓
后续:explorer ↔ ShellExperienceHost直接LRPC;资源访问请求会回传给RuntimeBroker代理
高层 API 栈
IAppxBroker::ActivateApplication
├─ appmodel.dll:读取Appx包清单
├─ DeriveAppContainerSidFromAppContainerName
├─ DuplicateTokenEx(advapi32 → lsass)
│ └─ NtDuplicateToken (ntdll)
├─ CreateAppContainerProfile(userenv.dll)
│ └─ NtCreateAppContainerProfile(原生API)
└─ CreateProcessAsUserW
└─ NtCreateProcessEx / NtCreateThreadEx
资源代理子链路(UWP 进程访问受限资源)
ShellExperienceHost(AppContainer低IL)
↓ COM请求 RuntimeBroker
RuntimeBroker使用**用户主令牌**执行文件/注册表访问
↓ 返回结果给ShellExperienceHost
四、配套链(工具、事件、取证)
运维 / 取证工具
Get-AppxPackage:查询 App 包名称、版本、能力声明- Process Explorer:查看进程令牌,检查 AppContainer SID、完整性级别
- accesschk.exe:校验 AppContainer SID 对资源的 ACL 访问权限
- OleViewDotNet:浏览
IAppxBrokerCOM 接口、AppID 安全描述符 Get-CapabilityPowerShell:查询 Capability 对应的 SID
事件日志
Microsoft-Windows-AppModel-Deployment:AppContainer Profile 创建、包注册、激活事件Microsoft-Windows-Security-Auditing(安全审计)- 4624:登录(AppContainer 受限令牌登录)
- 4656:打开 AppContainer 内核对象
- 4688:进程创建(RuntimeBroker 孵化 UWP 进程)
- DCOM Operational 日志:10016(AppContainer 客户端调用外部 COM 权限不足)
关联进程生态
| 进程 | 角色 |
|---|---|
| RuntimeBroker.exe | AppContainer 代理,父进程,IAppxBroker COM 实现 |
| explorer.exe | 桌面外壳,触发 UWP 激活请求 |
| DcomLaunch(svchost) | DCOM 本地激活调度 |
| ShellExperienceHost.exe / StartMenuExperienceHost.exe | 被孵化的 AppContainer 子进程 |
五、边界、安全边界、限制
✅ 功能边界
- 职责边界:只负责 AppContainer 环境创建与资源代理;不负责 UI 渲染(XAML 由子进程完成)。进程创建完成后,RuntimeBroker 不再参与子进程 UI 逻辑。
- 会话绑定:AppContainer 令牌派生自当前登录会话,用户注销,该会话所有 AppContainer 容器销毁。
- 能力是静态声明:Capability 在 AppxManifest 打包时声明;RuntimeBroker 仅在构建令牌时注入对应的 Capability SID,不能动态新增能力。
- 多实例:单个 RuntimeBroker 实例可以同时孵化多个 AppContainer 子进程。
⚠️ 安全边界(攻防 / 取证重点)
- 权限模型:RuntimeBroker 自身运行在普通登录用户令牌,不是 SYSTEM;它只是代理转发资源请求,不会自动提升权限。
- 沙箱强度:AppContainer 属于 Windows 强制访问控制隔离,不是强安全沙箱;历史存在 RuntimeBroker 接口漏洞,可实现沙箱逃逸,提升到父用户权限。
- 入口面:
IAppxBrokerCOM 接口(本地 LRPC),普通登录用户可调用,是攻击入口。 - 10016 DCOM 日志:是AppContainer 子进程作为客户端访问外部 COM 组件被 ACL 拒绝,不是 RuntimeBroker 自身漏洞。
❌ 技术局限
- 仅 UWP/Appx 包走此链路;普通 Win32 进程(notepad、cmd)不经过 RuntimeBroker,不创建 AppContainer 令牌。
- AppContainer 虚拟化注册表仅拦截写入,读取仍可访问真实系统注册表。
- 部分内核对象、WMI 命名空间、COM 对象默认对 AppContainer SID 拒绝访问。
取证边界
- 进程树特征:UWP AppContainer 进程的父进程为 RuntimeBroker.exe,可作为取证标记。
- 令牌特征:进程令牌包含
S-1-15-2-*SID + Low 强制完整性标签。 - 内存取证:RuntimeBroker 内存中存在 App 包全名、AppContainer 名称、Capability 列表、SID 信息。
- 注册表 slack:AppContainer 历史 Profile 记录,可提取曾经运行过的 UWP 包。
RuntimeBroker.exe(Windows Runtime Broker 运行时代理)完整拆解解构
术语概述
C:\Windows\System32\RuntimeBroker.exe核心定位:UWP 应用运行在AppContainer 低完整性沙箱,无法直接访问系统敏感资源;RuntimeBroker 运行在中等完整性 Medium IL,作为权限代理、WinRT COM 激活中介,统一拦截、校验、代理应用对受保护能力(Capability)的访问。区分:传统 Win32 程序不经过 RuntimeBroker;仅 UWP、MSIX 打包桌面应用、部分系统现代组件依赖它。
一、底层原理
1. 安全架构模型
UWP App(AppContainer,Low IL 沙箱)
↓ IPC/COM/WinRT调用(无法直接访问硬件/隐私资源)
RuntimeBroker.exe(Medium IL 权限中介)
↓ 权限校验、代理转发
系统资源:摄像头、麦克风、位置、联系人、文档库、剪贴板、通知、WinRT系统组件
2. 四大核心机制
(1)AppContainer 沙箱权限仲裁
PackageManifest.xml) 预先声明 Capability;RuntimeBroker 比对:
(2)WinRT COM 类托管与激活
(3)权限弹窗调度
(4)多实例模型
- RuntimeBroker.exe:通用运行时代理,多个应用可复用;
- PerAppRuntimeBroker.exe:单应用独立 Broker,强隔离场景一应用一进程。
任务管理器看到多条 RuntimeBroker,属于正常现象。
3. 关键安全设计思想
- 权限提升隔离:低权限沙箱 App 不能直接调用高权限系统 API;由独立 Broker 代理,缩小攻击面;
- 统一审计点:所有隐私资源访问集中经过 Broker,便于日志追踪;
- 动态权限生效:设置中随时撤销权限,无需重启应用,下一次 API 调用立即拦截。
4. 管控的典型 Capability 能力
二、依赖文件与核心组件
1. 主程序
RuntimeBroker.exe
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}2. 核心加载 DLL
combase.dll:COM/WinRT 底层通信基础ole32.dll:OLE/COM 调度winrt.dll:Windows Runtime 核心库kernel32.dll、ntdll.dll、user32.dll基础系统库cryptbase.dll:安全令牌、权限校验支撑
3. 注册表关键路径
; WinRT类注册信息
HKLM\SOFTWARE\Microsoft\WindowsRuntime
; DCOM配置
HKCR\AppID\{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
; AppContainer沙箱配置
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer
; 应用隐私权限存储
HKCU\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore
4. 事件日志路径
应用程序和服务日志 → Microsoft → Windows → AppModel-RuntimeBroker\Operational5. 配套协作进程
RPCSS.exe:COM/RPC 服务,负责 WinRT 对象跨进程激活sihost.exe:Shell 体验主机,协助弹出权限授权窗口explorer.exe:桌面 ShellBackgroundTaskHost.exe:UWP 后台任务宿主,与 Broker 协同校验后台能力AppXSvc:AppX 部署服务,提供应用包清单信息
三、依赖关系
硬性强制依赖
- RPCSS(COM 服务)
RuntimeBroker 本质是 DCOM 服务器,没有 RPCSS 无法接收 UWP 应用跨进程调用;
- AppContainer 安全子系统(内核层支持);
- WinRT 运行时组件;
- 用户会话环境(在登录用户会话内运行,无法在会话 0 运行)。
可选依赖
- Windows 推送通知服务 (WpnService):处理应用通知相关权限;
- 位置服务 (Locationservice)、Windows 音频 / 相机服务:对应硬件能力校验;
- AppXSvc:读取应用包 Manifest 声明的 Capability。
不依赖
- 不需要 IIS、RDS 组件(和前文 RD 系列 Broker 完全无关,只是名字都叫 Broker,体系独立);
- 不依赖 Hyper-V;
- 传统 Win32 软件运行不触发 RuntimeBroker。
约束与限制
- 无法直接结束进程:强行终止会导致所有 UWP 应用闪退、相机 / 定位等功能失效;
- 只管控声明式 Capability 权限,无法阻止应用访问沙箱内私有目录;
- MSIX 打包 Win32 只有使用 WinRT 隐私 API 时才经过 Broker;纯传统 Win32 API 不受管控。
四、完整逻辑链路
链路 A:UWP 应用请求摄像头权限(标准流程)
1. 用户启动UWP应用,系统创建AppContainer沙箱进程;
2. 应用调用WinRT API请求访问摄像头;
3. API层检测为受保护Capability,封装COM请求转发至RPCSS;
4. RPCSS激活RuntimeBroker.exe,建立跨进程通道;
5. RuntimeBroker执行三重校验:
① 读取应用PackageManifest,确认应用已声明摄像头能力;
② 查询CapabilityAccessManager注册表,读取用户隐私授权状态;
6. 分支1【已授权】
RuntimeBroker代理调用系统相机服务,打通数据流;摄像头画面经由Broker中转给应用;
7. 分支2【未授权】
RuntimeBroker通知sihost.exe弹出系统授权弹窗;
用户选择允许 → 写入注册表授权记录,建立访问通道;
用户选择拒绝 → 返回访问拒绝错误给应用;
8. 应用持续使用资源期间,Broker维持代理会话;
9. 应用退出 → Broker释放资源句柄;无其他应用使用时,一段时间后自动退出RuntimeBroker实例。
链路 B:WinRT 对象激活流程
UWP App → 请求实例化LocationTracker(WinRT类)
→ RPCSS路由激活请求
→ RuntimeBroker进程内加载对应WinRT组件
→ Broker持有对象实例,向App暴露代理接口
→ App所有调用经过Broker权限校验
典型异常分支
五、配套运维链
1. 常用诊断命令
# 查看进程与模块
tasklist | findstr RuntimeBroker
# 列出已安装UWP包
Get-AppxPackage
# 清理权限存储(谨慎使用)
# 监控ETW追踪AppModel-RuntimeBroker日志
2. 故障排查顺序
- 确认进程路径:必须位于
System32,路径异常警惕恶意程序伪装; - 事件日志查看 AppModel-RuntimeBroker 报错;
- 检查 DCOM 配置 RuntimeBroker 本地激活权限;
- 验证
CapabilityAccessManager注册表权限; - 高 CPU 场景:定位关联 UWP 应用,卸载异常应用或重置应用包;
- 系统文件修复:
sfc /scannow && DISM /Online /Cleanup-Image /RestoreHealth
六、运维风险与认知误区
- 重大概念误区
RuntimeBroker ≠ RD Connection Broker / RD Gateway。二者名称都含 Broker,但属于两套完全独立体系:
- RuntimeBroker:UWP 应用权限中介(客户端本地进程);
- RD 系列 Broker:微软远程桌面 RDS 调度网关(服务器远程桌面组件),互不调用。
-
高 CPU 常见诱因:某款 UWP 应用频繁反复请求权限、后台轮询 WinRT API,持续驱动 Broker 工作;并非 Broker 本身故障。
-
安全边界认知:RuntimeBroker 是攻击热点历史多发区域(多条 EoP 权限提升漏洞);原理根源:Low IL 沙箱进程与 Medium IL Broker 跨进程 IPC,一旦 IPC 解析缺陷即可提权。
-
不能禁用:禁用相关组件会导致照片、相机、商店应用、设置等现代 App 全部无法正常工作。
七、横向对比:各类 Windows Broker 进程区分
| 进程 | 归属体系 | 核心职能 | 运行环境 |
|---|---|---|---|
| RuntimeBroker.exe | UWP/AppModel | 应用隐私权限、WinRT 代理 | Windows 客户端 / 服务器通用 |
| PerAppRuntimeBroker.exe | UWP | 单应用隔离版 RuntimeBroker | Win10/11 |
| Tssdis.exe(RD Connection Broker) | RDS 远程桌面 | 远程会话调度负载均衡 | 仅 RDS 服务器角色 |
| TSGateway.exe(RD Gateway) | RDS | 外网 RDP 隧道代理 | 仅 RDS 网关服务器 |
RuntimeBroker.exe 是 Windows 操作系统中的一个系统进程,它负责管理 Metro 应用程序(现在称为 Universal Windows Platform 应用程序)的权限和沙盒环境。该进程通常在用户登录后启动,并且对于每个用户会话都会有一个实例在运行。
具体来说,Runtime Broker 主要有以下作用:
-
权限管理: Metro 应用程序(UWP 应用程序)在 Windows 环境中处于沙盒中,意味着它们被限制在受控的环境中运行,不能直接访问系统资源。Runtime Broker 负责管理这些应用程序的权限,以确保它们只能访问其被授权的资源。
-
资源分配: Runtime Broker 还负责分配和管理应用程序使用的系统资源,如内存和处理器时间,以确保系统的稳定性和性能。
-
运行环境: 它提供了一个安全的执行环境,以隔离 Metro 应用程序,防止它们对系统造成不良影响。
通常情况下,用户不需要直接与 Runtime Broker 交互,它在后台默默地运行并完成其工作。但是,如果发现 Runtime Broker 占用了大量的系统资源,可能会导致系统变慢,此时可能需要检查是否有某个 Metro 应用程序出现了问题,或者进行系统调优来解决资源占用过高的问题。

浙公网安备 33010602011771号