传统横向移动：
  PSExec         → 创建服务进程 → EDR 检测到服务创建异常
  WMI 远程执行   → WmiPrvSE.exe 子进程异常 → 被 EDR 关联
  WinRM          → 新进程创建 + 命令行参数 → 被 EDR 拦截
  SMB + PsExec    → 远程管道通信 → 网络层检测

共同特点：
  都需要"远程连接 → 创建新进程 → 执行命令"
  这些行为在 EDR 中都有成熟的检测规则

CSA 的思路：

  不需要"远程连接"（从网络层触发）
  不需要"创建新进程"（从攻击者视角）
  
  而是：
    利用 Windows COM/DCOM 机制
    在【目标机器本地】激活一个 COM 对象
    该 COM 对象被配置为 "RunAs = Interactive User"
    → Windows 自动在交互式用户的会话中启动它
    → 代码以目标用户的身份执行
  
  本质：让 Windows "合法地"帮你在另一个用户的会话里启动程序

传统横向移动：
  攻击者 → 远程连接 → 创建新进程 → 在远程机器上执行
  特征：有远程连接痕迹、有进程创建痕迹

Cross-Session Activation：
  攻击者 → 本地/远程 COM 激活 → Windows 自动在目标会话启动进程
  特征：COM 调用是合法行为、进程启动由 Windows Loader 触发

COM  = 本地进程间通信（Component Object Model）
DCOM = 跨网络的进程间通信（Distributed COM）

DCOM 是 Windows 内置的远程 COM 支持，不需要额外安装任何组件
只要网络可达 + 有权限，就能远程激活目标机器上的 COM 对象

攻击者已在这台机器上有管理员权限（如服务账户）
目标：借用另一个交互式用户的身份执行代码

攻击者（会话 0，服务账户）
  → 激活本机的 COM 对象
  → 通过 SetSessionId 切换到目标会话
  → 代码在 Administrator（会话 1）中执行

典型场景：
  - 攻击者通过 Web 漏洞获得了服务账户权限
  - 服务账户权限有限，想借用管理员的身份
  - 发现管理员正在使用这台机器
  → 用 CSA 在管理员会话中执行代码

攻击者在机器 A（10.0.0.10）
目标：在机器 B（10.0.0.13）的用户会话中执行代码

机器 A 的攻击者
  → 通过 DCOM 远程激活机器 B 上的 COM 对象
  → 代码在机器 B 的 Administrator（会话 1）中执行

典型场景：
  - 攻击者在内网横向移动中
  - 发现机器 B 有管理员正在使用
  - 通过 DCOM 在机器 B 的管理员会话中执行代码
  → 实现横向移动，且行为隐蔽

为什么远程跨机器可行？

1. DCOM 是 Windows 内置功能
   CoCreateInstanceEx() 可以指定远程机器 IP
   Windows 自动通过 RPC/DCOM 协议与远程机器通信
   在远程机器上创建 COM 对象实例

2. 远程注册表服务
   RemoteRegistry 服务允许远程读写注册表
   攻击者通过它远程修改 CLSID 的 InprocServer32/LocalServer32
   将 DLL/EXE 路径改为恶意载荷

3. 远程会话枚举
   WTSOpenServer + WTSEnumerateSessions 可以跨网络查询会话
   攻击者可以批量扫描网段，找到有交互式会话的目标

4. 远程 COM 激活
   COM 对象的 AppID 配置了 LaunchPermission
   如果包含远程激活权限 + 攻击者有管理员凭证
   → 可以在远程机器的指定会话中激活 COM 对象

远程 CSA 比本地 CSA 多出以下检测特征：

  1. 网络流量
     DCOM/RPC 通信（端口 135 + 动态端口）
     WMI 通信（端口 135 + 动态端口）

  2. WMI 痕迹
     目标机器上 WmiPrvSE.exe 创建子进程
     Win32_Process.Create 调用记录

  3. 远程注册表访问
     远程注册表连接事件
     Event ID 4663 中的远程来源

  4. SMB 文件传输
     copy \\<TARGET>\C$\... 的网络日志
     SMB 共享访问日志

CSA 既可以本地跨会话，也可以跨机器横向移动
  - 本地：无网络痕迹，主要用于权限提升（借用管理员身份）
  - 远程：通过 DCOM，主要用于横向移动（跨机器执行）
  - 两者共享相同的 COM 劫持原理，区别在于"从哪里发起激活"

COM（Component Object Model）= 组件对象模型

Windows 的核心架构之一，允许不同程序之间互相调用功能
例如：
  Excel 调用 Word 打开文档 → 通过 COM
  右键文件选择"打开方式" → 通过 COM 找到能处理的应用
  系统服务之间互相通信 → 通过 COM/DCOM

COM 对象存储在 Windows 注册表中
每个 COM 对象有唯一的 CLSID（Class ID，GUID 格式）

CLSID（Class ID）= COM 对象的身份证号
  格式：{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
  例如：{F87B28F1-DA9A-4F35-8EC0-800EFCF26B83}（sppui）

AppID（Application ID）= COM 应用的配置文件
  存放位置：HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID
  包含：启动方式、运行身份、权限配置等

AppID 注册表中的 RunAs 字段决定了 COM 对象以什么身份运行：

  RunAs = "Interactive User"  → 以当前交互式用户身份运行
  RunAs = "Launching User"    → 以启动它的用户身份运行
  RunAs = "System Account"    → 以 SYSTEM 身份运行

CSA 攻击利用的就是 RunAs = "Interactive User" 的 COM 对象
因为这类 COM 对象会在"正在使用电脑的用户"的会话中启动

Windows 会话 = 用户的独立工作空间

每台 Windows 机器可以同时有多个会话：
  会话 0：系统服务运行空间（svchost、lsass 等）
  会话 1：第一个交互式用户（你看到的桌面）
  会话 2：第二个用户通过 RDP 登录
  会话 3：第三个用户通过 RDP 登录

每个会话有独立的：
  桌面 / 窗口站
  进程空间
  注册表用户配置（HKCU）
  环境变量

CSA 的核心条件：目标用户必须有活跃的交互式会话

原因：
  RunAs = Interactive User 的 COM 对象
  只能在有"正在使用电脑"的用户的会话中启动
  
  如果目标用户断开了 RDP（状态 Disc）
  → 没有交互式会话
  → COM 对象无法在该会话中激活
  → 攻击失败

攻击者已经在目标机器上获得了代码执行权限（如通过 Web 漏洞）
目标：借用另一个交互式用户的身份执行代码

攻击者在机器 A，要远程在机器 B 的用户会话中执行代码
这是 CSA 作为横向移动技术的核心场景

┌─────────────────────────────────────────────────────────┐
│  步骤 1：枚举符合条件的 COM 对象                         │
│  找到 RunAs = Interactive User 的 CLSID                  │
├─────────────────────────────────────────────────────────┤
│  步骤 2：枚举目标会话                                    │
│  确定目标用户的会话 ID 和交互状态                         │
├─────────────────────────────────────────────────────────┤
│  步骤 3：准备执行环境                                    │
│  启动远程注册表服务，上传 DLL/EXE                         │
├─────────────────────────────────────────────────────────┤
│  步骤 4：发现可劫持路径                                  │
│  用 ComDiver 找到可写且优先级更高的注册表路径              │
├─────────────────────────────────────────────────────────┤
│  步骤 5：执行 COM 劫持                                   │
│  写入恶意 DLL/EXE 路径到注册表                           │
├─────────────────────────────────────────────────────────┤
│  步骤 6：激活 COM 对象                                   │
│  在目标会话中激活 COM 对象，代码执行                      │
└─────────────────────────────────────────────────────────┘

1. RunAs = Interactive User
2. LaunchAccess = Remote Activation
3. LaunchPrincipal = Everyone / Administrator / Empty

会话枚举需要的 API：
  WTSOpenServer          → 连接到远程终端服务器
  WTSEnumerateSessions   → 枚举所有会话
  WTSQuerySessionInformation → 查询会话详细信息

CSA 攻击需要修改目标机器的注册表（CLSID 劫持）
如果攻击者已经在目标机器上有进程 → 可以直接修改本地注册表
如果攻击者通过网络远程攻击 → 需要 RemoteRegistry 服务来远程修改

RemoteRegistry 默认在现代 Windows 上是禁用的
但管理员可以远程启动它

[+] Analyzing CLSID: {F87B28F1-DA9A-4F35-8EC0-800EFCF26B83}
[+] Total CLSID: 1

[+] Username: MSI\\panag          ← 当前操作用户
[+] RunAs Value: Interactive User  ← ✓ 符合 CSA 条件
[+] Process: slui.exe              ← 该 COM 对象会启动的进程
[+] PID: 48724
[+] Disk Path: C:\Windows\System32\slui.exe
[+] Registry Path: HKLM\SOFTWARE\Classes\CLSID\{...}\LocalServer32

[?] Load priority hijacking:

  [1] Writable:  HKCU\...\TreatAs           (Does not exist) ← 可写，可新建
  [2] Non Writable: HKLM\...\TreatAs        (Does not exist)
  [3] Writable:  HKCU\...\InprocServer32    (Does not exist) ← ★ 最佳目标
  [4] Non Writable: HKLM\...\InprocServer32 (Does not exist)
  [5] Writable:  HKCU\...\LocalServer32     (Does not exist) ← 可选目标
  [6] Non Writable: HKLM\...\LocalServer32  (Exists)         ← 原始配置，不可写

  [6] Real Path: HKLM\Software\Classes\CLSID\{...}\LocalServer32

Windows 注册表覆盖规则：

  HKCU（当前用户级）优先级 > HKLM（机器级）

  正常情况：
    HKCU 没有 InprocServer32 → 用 HKLM 的原始配置 → 加载合法 DLL

  劫持后：
    攻击者在 HKCU 新建 InprocServer32 → 指向恶意 DLL
    Windows 优先读 HKCU → 加载恶意 DLL

在目标机器的注册表中创建/修改：

  HKCU\Software\Classes\CLSID\{F87B28F1...}\InprocServer32
  默认值 = C:\temp\demon.x64.dll

  这样当该 COM 对象被激活时：
    Windows 检查 HKCU → 发现 InprocServer32
    → 加载 C:\temp\demon.x64.dll
    → DLL 的 DllMain 执行 → 代码在目标用户会话中运行

步骤 6.1：CoCreateInstance 创建 COM 对象
  → 获取接口指针

步骤 6.2：QueryInterface 查询 ISpecialSystemProperties 接口
  → 获取设置会话 ID 的能力

步骤 6.3：SetSessionId 设置目标会话 ID
  → 告诉 COM 对象："在会话 X 中激活"

步骤 6.4：StandardGetInstanceFromIStorage
  → 在目标会话中创建 COM 对象实例
  → Windows 启动对应的进程（如 HelpPane.exe / slui.exe）
  → 加载被劫持的 DLL
  → 代码在目标用户的上下文中执行

前提：该 COM 对象的接口恰好提供了能执行命令的方法

典型代表：IHxHelpPaneServer
  接口定义：

Execute() 方法的发现过程：

  1. COM 接口定义是公开的（IDL 文件、Windows SDK 头文件）
  2. 安全研究员通过 oleview / oleviewdotnet 查看 COM 接口
  3. 发现 IHxHelpPaneServer 有 Execute() 方法
  4. 结合 CVE-2024-38100 的跨会话执行问题
  5. 发布了 IHxExec 和 SessionHop PoC

为什么 Execute() 能被滥用？
  原始设计：HelpPane.exe 是帮助面板，Execute() 用于打开用户请求的帮助文件
  攻击者视角：Execute() 可以执行任意文件路径 → 被用来执行恶意代码

SessionHop 使用 Session Moniker（会话标识器）技术：
  1. 创建一个指向目标会话的 Moniker
  2. 通过 Moniker 激活 IHxHelpPaneServer COM 对象
  3. 调用 Execute() 接口执行任意文件
  4. 代码在指定会话中以该会话用户的身份运行

前提：该 COM 对象没有直接的 Execute() 方法
但配置为 Interactive User，且可以劫持其 DLL 加载路径

典型代表：sppui（Software Protection Platform User Interface）
  这个 COM 对象用于管理 Windows 许可证和激活
  它没有 Execute() 方法
  但通过内部的 WMI 调用可以间接执行命令

sppui 攻击流程：
  1. 通过 WMI 连接到目标主机（使用提供的凭证）
  2. CoCreateInstanceEx 激活 sppui COM 对象
  3. 通过 sppui 的内部接口触发 WMI 调用
  4. WMI 的 Win32_Process.Create 执行任意命令
  5. 命令在目标会话中以目标用户权限运行

SessionHop（模式 A）：
  COM 对象有 Execute() 方法
  → 直接调用 Execute()
  → 最简单直接
  → HelpPane.exe 会启动

sppui（模式 B）：
  COM 对象没有 Execute() 方法
  → 通过 WMI 间接执行
  → 更隐蔽，但流程更复杂
  → slui.exe + WmiPrvSE.exe 会启动

本质区别：COM 对象提供的接口方法不同，导致利用方式不同

取决于目标环境：

  1. 枚举所有 RunAs=Interactive User 的 CLSID
  2. 检查每个 CLSID 的接口方法
     → 有 Execute() 或类似方法 → 模式 A
     → 没有直接方法 → 看能否走间接路径（WMI 等）→ 模式 B
  3. 考虑检测难度
     → IHxHelpPaneServer：HelpPane.exe 在现代 Windows 上罕见，容易被发现
     → sppui：WMI 活动在企业中常见，更难区分正常和异常
  4. 选择阻力最小的路径

CoCreateInstance / CoCreateInstanceEx
  ↓
  创建 COM 对象实例
  获取接口指针

QueryInterface（ISpecialSystemProperties）
  ↓
  查询特殊系统属性接口
  用于获取设置会话 ID 的能力

SetSessionId
  ↓
  设置目标会话 ID
  告诉 COM 在哪个会话中激活

StandardGetInstanceFromIStorage
  ↓
  从存储对象创建新实例
  在目标会话中触发 COM 对象启动

CVE-2024-38100：
  影响组件：Windows HelpPane.exe（帮助面板）
  漏洞类型：权限提升 / 跨会话执行
  发现时间：2024年

  HelpPane.exe 原本用于显示 Windows 帮助内容
  在 Windows 10/11 中已停止使用，但可执行文件仍存在
  
  漏洞本质：
    IHxHelpPaneServer COM 对象的 Execute() 方法
    可以在任意会话中执行任意文件
    而 Windows 没有对此进行适当的权限检查

1. 攻击者获取目标机器的管理员权限
2. 找到有活跃交互式会话的目标用户
3. 创建 IHxHelpPaneServer COM 对象
4. 通过 SetSessionId 切换到目标用户会话
5. 调用 Execute() 执行恶意文件
6. 恶意代码以目标用户权限在目标会话中运行

CVE-2024-38100 是 CSA 技术的一个具体利用案例
CSA 是更广泛的技术类别，CVE-2024-38100 只是其中一种实现

CSA 不一定需要 CVE：
  如果有 DLL 劫持路径 → 不需要特定 CVE
  如果 COM 对象有可滥用的方法 → 可以直接利用
  CVE-2024-38100 只是让 IHxHelpPaneServer 的利用更加直接

CSA 攻击涉及多个合法 Windows 行为：

  ① 修改注册表 → 合法的注册表操作
  ② COM 激活 → 合法的 COM 调用
  ③ 进程启动 → 合法的进程创建
  ④ 命令执行 → 合法的命令执行

单独看每一步都"正常"
必须把它们关联起来才能发现异常

HelpPane.exe 正常行为：
  启动 → 打开浏览器显示帮助 → 结束
  只会生成浏览器子进程（iexplore.exe / msedge.exe）

HelpPane.exe 被 CSA 利用后：
  启动 → Execute("malware.exe") → malware.exe 启动
  malware.exe 不是浏览器 → 告警！

为什么有效：
  Windows 10/11 已停止使用 HelpPane
  任何 HelpPane.exe 的启动本身就是可疑行为
  加上非浏览器子进程 → 高置信度告警

DeviceProcessEvents
| where InitiatingProcessFileName =~ "HelpPane.exe"
| where FileName !in~ ("HelpPane.exe","iexplore.exe","msedge.exe","msedgewebview2.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, InitiatingProcessSessionId, ProcessId

监控以下进程的异常启动：

  HelpPane.exe    → IHxHelpPaneServer COM 对象触发
  slui.exe        → sppui COM 对象触发
  WmiPrvSE.exe    → 远程 CSA 通过 WMI 触发时出现

异常判断标准：
  ① 进程在不该出现的时间出现
  ② 父进程不符合常规模式
  ③ 子进程不符合该进程的正常行为

组策略路径：
Computer Configuration → Policies → Windows Settings →
Security Settings → Advanced Audit Policy Configuration →
Audit Policies → Object Access → Audit Registry

设置为：Success

组策略路径：
Computer Configuration → Policies → Windows Settings →
Security Settings → Registry

添加需要监控的 CLSID 注册表键：
  HKLM\SOFTWARE\Classes\CLSID\{F87B28F1...}\LocalServer32
  HKLM\SOFTWARE\Classes\CLSID\{924DC564...}\LocalServer32
  HKLM\SOFTWARE\Classes\CLSID\{8cec592c...}\LocalServer32
  ...（所有已知高危 CLSID）

在 Event ID 4663 中关注以下操作：

  SetValue       → 修改 DLL/EXE 路径（最直接的攻击行为）
  Create Subkey  → 新建 InprocServer32（HKCU 里新建键）
  Delete         → 删除原始路径（掩盖痕迹）
  Write DAC      → 修改权限（为了持久化）

告警条件：
  Event ID 4663
  + 对象名包含高危 CLSID
  + 访问类型是 SetValue / Create Subkey
  + 主体是 Everyone 或 Authenticated Users
  + 时间集中在同一个窗口期

时间窗口（5分钟内）同时出现：

  进程 A 调用了 WTSOpenServer + WTSEnumerateSessions
  → 紧接着调用了 CoCreateInstance
  → CoCreateInstance 的 CLSID 是已知高危 CLSID
  → 告警！

时间窗口（5分钟内）同时出现以下行为：

  [1] Event ID 4663：某 CLSID 的注册表键被写入
       ↓
  [2] API 调用：WTSEnumerateSessions（会话枚举）
       ↓
  [3] CoCreateInstance 被调用（COM 对象激活）
       ↓
  [4] Event ID 4688：HelpPane.exe 或 slui.exe 启动
       ↓
  [5] Event ID 4688：HelpPane.exe 的子进程是非浏览器

  → 告警置信度：Critical

单条告警可能误报
但 5 条关联 = 几乎确定是 CSA 攻击

1. 枚举环境中所有 RunAs=Interactive User 的 CLSID
2. 确认哪些 CLSID 业务上真正需要
3. 对不需要的 CLSID：
   → 修改 RunAs 配置（改为Launching User 或 System Account）
   → 或直接禁用该 COM 类
4. 禁用不需要的 RemoteRegistry 服务

1. 对已知高危 CLSID 启用注册表审计
2. 监控 SetValue / Create Subkey / Delete / Write DAC 操作
3. 在组策略中添加 CLSID 监控规则
4. 配合 Sysmon RegistryEvent 进行实时监控

1. HelpPane.exe 出现 → 立即关注（现代 Windows 不应正常使用）
2. slui.exe 非正常启动 → 告警
3. WmiPrvSE.exe 创建子进程 → 关联其他行为判断
4. 关注父-子进程异常关系

与 EDR 厂商确认以下能力：
  1. 是否钩子了 WTSOpenServer / WTSEnumerateSessions / WTSQuerySessionInformation
  2. 是否能监控 CoCreateInstance 调用及参数
  3. 是否能关联注册表修改和进程创建
  4. 是否能检测跨会话的 COM 激活

当告警触发时：

1. 确认告警来源进程是否为高价值目标
2. 检查事件时间窗口内的所有相关行为：
   - 注册表写入（Event ID 4663）
   - 进程创建（Event ID 4688）
   - API 调用（WTSOpenServer 等）
3. 确认被利用的 CLSID 和受影响的会话
4. 检查目标会话用户是否有异常出站连接
5. 取证：记录注册表修改内容、进程创建链
6. 回溯攻击链：WriteProcessMemory 的来源进程
7. 隔离受影响会话，终止可疑进程

CSA 攻击有以下限制：

1. COM 对象必须配置为 RunAs=Interactive User
   → 不是所有 COM 对象都满足
   → 这是 CSA 的定义性条件，无法绕过

2. 目标必须有活跃的交互式会话
   → 断开的 RDP 会话（Disconnected）不行
   → 会话 0（系统服务）的用户不行
   → 这意味着攻击者必须等待管理员"在线"才能触发

3. COM 类必须提供能执行命令或文件的方法
   → 或者可以通过 DLL 劫持间接执行
   → 不是所有 COM 对象都有 Execute() 这样的方法

4. 远程场景需要管理员权限 + RemoteRegistry
   → 本地场景不一定需要管理员权限（修改 HKCU 即可）
   → RemoteRegistry 默认禁用，需要管理员远程启动

5. CLSID 数量虽多，但每个都有特定条件
   → 防御方可以针对性监控

6. 时机依赖：必须等到目标用户交互式登录
   → 如果目标用户没有登录，攻击无法触发
   → 这给了防御方一个时间窗口

1. COM 滥用技术越来越成熟
2. 利用 Windows 合法机制的攻击越来越难检测
3. 检测重点从单点告警转向行为关联分析
4. CLSID 枚举和监控成为防御的基础工作