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);仅具备代理编排能力,不永久提权。

一、底层原理

  1. AppContainer 安全模型编排 AppContainer 是 SID + 强制完整性(Mandatory Integrity Control)的隔离模型。RuntimeBroker 读取 AppX 包清单(AppxManifest.xml),解析包声明的capabilities(internetClient、picturesLibrary 等),向 LSASS 请求派生受限访问令牌,附加 AppContainer SID(S-1-15-2-xxxx),设置低完整性级别,剥离管理员 SID 与高权限特权。
  2. COM/LRPC 激活调度 对外暴露 IAppxBroker 本地 COM 接口;由 DcomLaunch 接收 AppID 激活请求,转发至 RuntimeBroker。仅本地 LRPC,不开放远程 DCOM。

流程:DcomLaunch 发现目标 AppID 标记为 AppContainer 类型 → 调用 RuntimeBroker COM 接口,请求创建容器环境并启动进程。

  1. 隔离环境挂载 创建 AppContainer 内核配置文件对象,自动挂载:
  • 独立内核对象命名空间(容器进程默认无法访问全局互斥体 / 事件)
  • AppContainer 虚拟化注册表(HKCU 分支隔离,写时虚拟化)
  • 容器私有存储目录 %LOCALAPPDATA%\Packages\<包名>\
  1. 运行时资源代理(Broker 代理模型) AppContainer 进程是低 IL,无法直接访问多数系统资源。当 UWP 进程需要访问文件、注册表、设备、相机时,会调用 RuntimeBroker 的 COM 接口,由 RuntimeBroker 使用用户主令牌代为执行访问,完成权限中转。
  2. 进程生命周期代理 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 运行时基础库

内核与系统服务依赖

  1. lsass.exe(本地安全机构):强依赖,令牌派生、SID 生成、安全策略校验。
  2. ntoskrnl.exe:AppContainer 内核对象、令牌对象、MIC 强制完整性、对象命名空间管理。
  3. DcomLaunch(svchost):DCOM 本地激活,发起 IAppxBroker 调用。
  4. RpcSs:LRPC 基础 RPC 服务。
  5. win32k.sys:窗口站、桌面会话隔离,UWP 窗口渲染基础。

注册表依赖

  1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository:已注册 Appx 包元数据
  2. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppContainer:AppContainer 全局策略
  3. HKCU\Software\Microsoft\Windows\CurrentVersion\AppContainer:用户侧容器配置文件
  4. HKCR\AppID\:UWP 系统 App(ShellExperienceHost 等)DCOM AppID 注册项

存储路径

  1. C:\Program Files\WindowsApps\:第三方 UWP 应用包
  2. C:\Windows\SystemApps\:系统内置 AppX 包(ShellExperienceHost 等)
  3. %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

四、配套链(工具、事件、取证)

运维 / 取证工具

  1. Get-AppxPackage:查询 App 包名称、版本、能力声明
  2. Process Explorer:查看进程令牌,检查 AppContainer SID、完整性级别
  3. accesschk.exe:校验 AppContainer SID 对资源的 ACL 访问权限
  4. OleViewDotNet:浏览IAppxBroker COM 接口、AppID 安全描述符
  5. Get-Capability PowerShell:查询 Capability 对应的 SID

事件日志

  1. Microsoft-Windows-AppModel-Deployment:AppContainer Profile 创建、包注册、激活事件
  2. Microsoft-Windows-Security-Auditing(安全审计)
    • 4624:登录(AppContainer 受限令牌登录)
    • 4656:打开 AppContainer 内核对象
    • 4688:进程创建(RuntimeBroker 孵化 UWP 进程)
  3. DCOM Operational 日志:10016(AppContainer 客户端调用外部 COM 权限不足)

关联进程生态

进程 角色
RuntimeBroker.exe AppContainer 代理,父进程,IAppxBroker COM 实现
explorer.exe 桌面外壳,触发 UWP 激活请求
DcomLaunch(svchost) DCOM 本地激活调度
ShellExperienceHost.exe / StartMenuExperienceHost.exe 被孵化的 AppContainer 子进程

五、边界、安全边界、限制

✅ 功能边界

  1. 职责边界:只负责 AppContainer 环境创建与资源代理;不负责 UI 渲染(XAML 由子进程完成)。进程创建完成后,RuntimeBroker 不再参与子进程 UI 逻辑。
  2. 会话绑定:AppContainer 令牌派生自当前登录会话,用户注销,该会话所有 AppContainer 容器销毁。
  3. 能力是静态声明:Capability 在 AppxManifest 打包时声明;RuntimeBroker 仅在构建令牌时注入对应的 Capability SID,不能动态新增能力。
  4. 多实例:单个 RuntimeBroker 实例可以同时孵化多个 AppContainer 子进程。

⚠️ 安全边界(攻防 / 取证重点)

  1. 权限模型:RuntimeBroker 自身运行在普通登录用户令牌,不是 SYSTEM;它只是代理转发资源请求,不会自动提升权限。
  2. 沙箱强度:AppContainer 属于 Windows 强制访问控制隔离,不是强安全沙箱;历史存在 RuntimeBroker 接口漏洞,可实现沙箱逃逸,提升到父用户权限。
  3. 入口面:IAppxBroker COM 接口(本地 LRPC),普通登录用户可调用,是攻击入口。
  4. 10016 DCOM 日志:是AppContainer 子进程作为客户端访问外部 COM 组件被 ACL 拒绝,不是 RuntimeBroker 自身漏洞。

❌ 技术局限

  1. 仅 UWP/Appx 包走此链路;普通 Win32 进程(notepad、cmd)不经过 RuntimeBroker,不创建 AppContainer 令牌。
  2. AppContainer 虚拟化注册表仅拦截写入,读取仍可访问真实系统注册表。
  3. 部分内核对象、WMI 命名空间、COM 对象默认对 AppContainer SID 拒绝访问。

取证边界

  1. 进程树特征:UWP AppContainer 进程的父进程为 RuntimeBroker.exe,可作为取证标记。
  2. 令牌特征:进程令牌包含S-1-15-2-* SID + Low 强制完整性标签。
  3. 内存取证:RuntimeBroker 内存中存在 App 包全名、AppContainer 名称、Capability 列表、SID 信息。
  4. 注册表 slack:AppContainer 历史 Profile 记录,可提取曾经运行过的 UWP 包。

RuntimeBroker.exe(Windows Runtime Broker 运行时代理)完整拆解解构

术语概述

RuntimeBroker.exe,简称 Runtime Broker,自 Windows 8 引入,是 UWP / 打包应用 (Appx/MSIX) 安全模型核心 Broker 中介进程。
 
可执行文件标准路径:
 
C:\Windows\System32\RuntimeBroker.exe
核心定位:
 
UWP 应用运行在AppContainer 低完整性沙箱,无法直接访问系统敏感资源;RuntimeBroker 运行在中等完整性 Medium IL,作为权限代理、WinRT COM 激活中介,统一拦截、校验、代理应用对受保护能力(Capability)的访问。
 
区分:
 
传统 Win32 程序不经过 RuntimeBroker;仅 UWP、MSIX 打包桌面应用、部分系统现代组件依赖它。

一、底层原理

1. 安全架构模型

plaintext
 
 
 
UWP App(AppContainer,Low IL 沙箱)
        ↓ IPC/COM/WinRT调用(无法直接访问硬件/隐私资源)
RuntimeBroker.exe(Medium IL 权限中介)
        ↓ 权限校验、代理转发
系统资源:摄像头、麦克风、位置、联系人、文档库、剪贴板、通知、WinRT系统组件
 

2. 四大核心机制

(1)AppContainer 沙箱权限仲裁

UWP 启动时绑定独立 AppContainer 安全令牌;沙箱默认隔离文件、注册表、硬件。
 
所有超出沙箱边界的资源请求,必须通过 WinRT COM 接口转发至 RuntimeBroker 校验。
 
App 包清单 (PackageManifest.xml) 预先声明 Capability;RuntimeBroker 比对:
 
① 应用是否在清单声明该能力;
 
② 用户隐私设置是否授予该权限;
 
二者同时满足才允许访问。

(2)WinRT COM 类托管与激活

WinRT(Windows Runtime)基于 COM 扩展;大量系统 WinRT 组件宿主在 RuntimeBroker 进程内(而非应用进程)。
 
应用不能直接实例化敏感 WinRT 对象,由 RPCSS → RuntimeBroker 完成对象激活,实现隔离。

(3)权限弹窗调度

当应用请求未授权资源时,RuntimeBroker 触发系统隐私授权弹窗,与 Shell (sihost.exe) 交互,采集用户允许 / 拒绝决策并持久化隐私配置。

(4)多实例模型

Windows 10/11 存在两类 Broker:
  1. RuntimeBroker.exe:通用运行时代理,多个应用可复用;
  2. PerAppRuntimeBroker.exe:单应用独立 Broker,强隔离场景一应用一进程。
任务管理器看到多条 RuntimeBroker,属于正常现象。

3. 关键安全设计思想

  • 权限提升隔离:低权限沙箱 App 不能直接调用高权限系统 API;由独立 Broker 代理,缩小攻击面;
  • 统一审计点:所有隐私资源访问集中经过 Broker,便于日志追踪;
  • 动态权限生效:设置中随时撤销权限,无需重启应用,下一次 API 调用立即拦截。

4. 管控的典型 Capability 能力

位置信息、摄像头、麦克风、图片 / 视频 / 文档库、联系人、日历、蓝牙、网络、剪贴板访问、通知、后台任务。

二、依赖文件与核心组件

1. 主程序

RuntimeBroker.exe
 
DCOM APPID:{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. 注册表关键路径

reg
 
 
 
; 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\Operational

5. 配套协作进程

  • RPCSS.exe:COM/RPC 服务,负责 WinRT 对象跨进程激活
  • sihost.exe:Shell 体验主机,协助弹出权限授权窗口
  • explorer.exe:桌面 Shell
  • BackgroundTaskHost.exe:UWP 后台任务宿主,与 Broker 协同校验后台能力
  • AppXSvc:AppX 部署服务,提供应用包清单信息

三、依赖关系

硬性强制依赖

  1. RPCSS(COM 服务)
     
    RuntimeBroker 本质是 DCOM 服务器,没有 RPCSS 无法接收 UWP 应用跨进程调用;
  2. AppContainer 安全子系统(内核层支持);
  3. WinRT 运行时组件;
  4. 用户会话环境(在登录用户会话内运行,无法在会话 0 运行)。

可选依赖

  1. Windows 推送通知服务 (WpnService):处理应用通知相关权限;
  2. 位置服务 (Locationservice)、Windows 音频 / 相机服务:对应硬件能力校验;
  3. AppXSvc:读取应用包 Manifest 声明的 Capability。

不依赖

  1. 不需要 IIS、RDS 组件(和前文 RD 系列 Broker 完全无关,只是名字都叫 Broker,体系独立);
  2. 不依赖 Hyper-V;
  3. 传统 Win32 软件运行不触发 RuntimeBroker。

约束与限制

  1. 无法直接结束进程:强行终止会导致所有 UWP 应用闪退、相机 / 定位等功能失效;
  2. 只管控声明式 Capability 权限,无法阻止应用访问沙箱内私有目录;
  3. MSIX 打包 Win32 只有使用 WinRT 隐私 API 时才经过 Broker;纯传统 Win32 API 不受管控。

四、完整逻辑链路

链路 A:UWP 应用请求摄像头权限(标准流程)

plaintext
 
 
 
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 对象激活流程

plaintext
 
 
 
UWP App → 请求实例化LocationTracker(WinRT类)
→ RPCSS路由激活请求
→ RuntimeBroker进程内加载对应WinRT组件
→ Broker持有对象实例,向App暴露代理接口
→ App所有调用经过Broker权限校验
 

典型异常分支

① AppManifest 未声明对应 Capability → Broker 直接拒绝访问,不弹出授权框;
 
② DCOM 权限异常(常见 10016 事件)→ 应用无法触发权限请求,功能报错;
 
③ 隐私注册表权限损坏 → 授权弹窗反复弹出、设置不生效;
 
④ RuntimeBroker 崩溃 → 所有关联 UWP 应用立刻丢失硬件 / 隐私资源访问。

五、配套运维链

1. 常用诊断命令

cmd
 
 
 
# 查看进程与模块
tasklist | findstr RuntimeBroker
# 列出已安装UWP包
Get-AppxPackage
# 清理权限存储(谨慎使用)
# 监控ETW追踪AppModel-RuntimeBroker日志
 

2. 故障排查顺序

  1. 确认进程路径:必须位于System32,路径异常警惕恶意程序伪装;
  2. 事件日志查看 AppModel-RuntimeBroker 报错;
  3. 检查 DCOM 配置 RuntimeBroker 本地激活权限;
  4. 验证CapabilityAccessManager注册表权限;
  5. 高 CPU 场景:定位关联 UWP 应用,卸载异常应用或重置应用包;
  6. 系统文件修复:sfc /scannow && DISM /Online /Cleanup-Image /RestoreHealth

六、运维风险与认知误区

  1. 重大概念误区
     
    RuntimeBroker ≠ RD Connection Broker / RD Gateway。
     
    二者名称都含 Broker,但属于两套完全独立体系:
  • RuntimeBroker:UWP 应用权限中介(客户端本地进程);
  • RD 系列 Broker:微软远程桌面 RDS 调度网关(服务器远程桌面组件),互不调用。
  1. 高 CPU 常见诱因:
     
    某款 UWP 应用频繁反复请求权限、后台轮询 WinRT API,持续驱动 Broker 工作;并非 Broker 本身故障。
  2. 安全边界认知:
     
    RuntimeBroker 是攻击热点历史多发区域(多条 EoP 权限提升漏洞);原理根源:Low IL 沙箱进程与 Medium IL Broker 跨进程 IPC,一旦 IPC 解析缺陷即可提权。
  3. 不能禁用:禁用相关组件会导致照片、相机、商店应用、设置等现代 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 主要有以下作用:

  1. 权限管理: Metro 应用程序(UWP 应用程序)在 Windows 环境中处于沙盒中,意味着它们被限制在受控的环境中运行,不能直接访问系统资源。Runtime Broker 负责管理这些应用程序的权限,以确保它们只能访问其被授权的资源。

  2. 资源分配: Runtime Broker 还负责分配和管理应用程序使用的系统资源,如内存和处理器时间,以确保系统的稳定性和性能。

  3. 运行环境: 它提供了一个安全的执行环境,以隔离 Metro 应用程序,防止它们对系统造成不良影响。

通常情况下,用户不需要直接与 Runtime Broker 交互,它在后台默默地运行并完成其工作。但是,如果发现 Runtime Broker 占用了大量的系统资源,可能会导致系统变慢,此时可能需要检查是否有某个 Metro 应用程序出现了问题,或者进行系统调优来解决资源占用过高的问题。


 

 

 

posted @ 2024-04-24 20:25  suv789  阅读(1968)  评论(0)    收藏  举报