如何确认 Windows 服务弱权限是否真正构成本地提权风险

背景与问题

在已授权的 Windows 内网测试中，经常会遇到这种情况：AccessChk 显示普通域用户对某个服务具有写权限，但实际验证时无法停止服务、修改后也没有立即生效，最终不确定该问题应定为高危提权，还是普通配置缺陷。

核心问题：普通用户对 Windows 服务拥有哪些权限时，才会形成可利用的权限边界突破？验证失败是否意味着不存在风险？

判断时不能只看服务是否以 LocalSystem 运行，也不能只依赖自动化工具的一行告警。至少需要同时核对服务对象权限、可执行文件权限、服务启动账户、触发条件和系统防护策略。

一、先区分三类服务弱权限

这三类问题可以同时存在，也可能完全独立。例如服务 DACL 很安全，但安装目录继承了 Users 的 Modify 权限，仍然可能形成提权风险。

二、收集服务配置与当前身份

建议先固定当前令牌、服务配置和启动账户，避免后续因为使用了管理员终端而得出错误结论。

whoami /user
whoami /groups
whoami /priv

Get-CimInstance Win32_Service |
  Select-Object Name,StartName,StartMode,State,PathName |
  Sort-Object Name

sc.exe qc AcmeAgent
sc.exe queryex AcmeAgent
sc.exe sdshow AcmeAgent

重点查看以下字段：

• StartName：LocalSystem、LocalService、NetworkService 或高权限域账户，决定潜在权限收益。
• PathName：确认路径是否使用双引号、是否携带参数，以及实际程序位置。
• StartMode：自动启动并不等于当前用户能立即触发，但可能在重启后形成稳定风险。
• State：正在运行且普通用户无停止权限时，直接验证通常不会立即生效。

三、正确理解服务 SDDL

服务对象的 SDDL 权限缩写与文件权限并不相同。排查时常见的关键值如下：

例如 ACE 中出现对 Authenticated Users、Users 或 Domain Users 授予 DC、WD、WO、GA，需要进一步确认是否为显式拒绝规则覆盖，以及当前用户的实际有效权限。不要把 CC 误判为修改配置；在服务对象中，CC 通常表示查询配置。

四、使用 AccessChk 验证有效权限

AccessChk 比单纯阅读 SDDL 更适合确认指定用户或组的有效访问权。应在低权限测试账户的上下文执行，或者明确指定账户。

# 枚举测试账户可写的服务对象
accesschk.exe -accepteula -uwcqv 'DOMAIN\audituser' *

# 查看单个服务的完整权限
accesschk.exe -accepteula -ucqv 'DOMAIN\audituser' AcmeAgent

# 检查服务程序及安装目录
accesschk.exe -accepteula -qv 'DOMAIN\audituser' 'C:\Program Files\Acme\agent.exe'
accesschk.exe -accepteula -qv 'DOMAIN\audituser' 'C:\Program Files\Acme'

# 使用系统自带工具复核文件 ACL
icacls 'C:\Program Files\Acme'
icacls 'C:\Program Files\Acme\agent.exe'

检查目录时不能只关注文件上的 Write。若用户对父目录拥有 Modify、Delete Child、创建文件或重命名权限，即使原文件本身没有直接写权限，也可能通过删除、移动和同名重建影响服务程序。

五、如何进行低影响验证

生产环境中不建议替换二进制文件、修改 ImagePath 或强制重启服务。若已经确认测试窗口和回滚方案，可以通过修改服务描述来验证 SERVICE_CHANGE_CONFIG，而不触碰执行路径。

$svc = 'AcmeAgent'
$old = (Get-CimInstance Win32_Service -Filter "Name='$svc'").Description

# 仅在变更窗口内执行，用工单号标记测试动作
sc.exe description $svc 'CHG-2025-0187 authorized ACL validation'

# 检查是否生效
Get-CimInstance Win32_Service -Filter "Name='$svc'" |
  Select-Object Name,Description

# 测试完成后恢复原值
sc.exe description $svc $old

修改服务描述同样需要相应配置权限。如果低权限账户可以完成该操作，基本可以证明 SERVICE_CHANGE_CONFIG 确实有效。该方法只用于确认权限边界，不代表可以忽略变更审批、备份和日志留存。

如果环境不允许任何配置写入，则保留 AccessChk 输出、SDDL、当前用户令牌和服务配置作为证据即可，不必为了展示危害而执行完整提权链。

六、未加引号路径不能只看字符串

假设服务路径为：

C:\Program Files\Vendor App\service.exe -d

路径未加引号时，理论上可能产生多个候选解析位置。但只有当前低权限用户能够在相应位置创建文件时，风险才成立。应依次核对候选父目录，而不是看到空格就直接报高危。

icacls 'C:\'
icacls 'C:\Program Files'
icacls 'C:\Program Files\Vendor App'

# 同时检查注册表中的原始 ImagePath
reg.exe query HKLM\SYSTEM\CurrentControlSet\Services\AcmeAgent /v ImagePath

# 检查服务注册表项 ACL
Get-Acl 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AcmeAgent' |
  Format-List Owner,AccessToString

还需要区分“能创建文件”和“能创建目录”。如果所有候选位置均不可写，单纯的未加引号路径通常只能作为配置加固项，而不能直接证明可提权。

七、为什么验证会失败

• 只有 SERVICE_CHANGE_CONFIG，没有 SERVICE_STOP 或 SERVICE_START，修改后无法立即触发。
• 服务正在运行，且停止操作受依赖关系或服务控制权限限制。
• 服务账户本身权限较低，修改后不存在明显权限收益。
• 可执行文件被 WDAC、AppLocker、应用控制或安全软件阻止。
• 服务属于受保护服务，普通管理员权限也未必能够直接修改。
• 修改的是显示名称、注册表副本或错误服务实例，而非实际 ImagePath。
• 服务配置存在恢复机制，代理程序或运维平台会自动还原。
• 服务程序启动失败并返回 1053。该错误只表示未及时响应服务控制管理器，不能单独证明进程从未被创建。

因此，“无法重启服务”只说明当前缺少即时触发条件，不代表配置修改权限本身没有安全影响。对于自动启动服务，系统维护重启后仍可能触发；报告中应将“可修改”和“可立即触发”分开描述。

八、日志留痕与取证

服务测试应记录准确时间、测试账户、主机名、服务名、变更前后值和恢复结果。Windows 默认日志对服务配置修改的覆盖并不完整，需要结合多种日志源。

# 服务安装、启动类型变化及状态变化
Get-WinEvent -FilterHashtable @{
  LogName='System'
  Id=7036,7040,7045
  StartTime=(Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,ProviderName,Message

# 安全日志：需提前启用相应审核策略
Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4657,4688,4697
  StartTime=(Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,Message

# 检查当前审核策略
auditpol.exe /get /subcategory:'Process Creation'
auditpol.exe /get /subcategory:'Security System Extension'
auditpol.exe /get /subcategory:'Registry'

• 7045 和 4697 主要记录新服务安装，不应被当作所有服务配置修改的通用告警。
• 7040 常用于启动类型变化，但不保证覆盖 ImagePath 等全部字段。
• 4657 需要启用注册表审核，并在目标注册表项上配置合适的 SACL。
• 4688 可以确认 sc.exe、PowerShell 或管理工具的进程创建，建议同时记录命令行。
• 部署 Sysmon 时，可结合事件 1、11、13 观察进程、文件创建和服务注册表项修改。

九、修复建议

• 依据厂商基线重建服务 DACL，移除 Users、Authenticated Users、Everyone 等宽泛主体的 DC、WD、WO 和 GA 权限。
• 不要直接复制其他主机的 SDDL。服务版本、依赖和管理代理不同，错误使用 sc.exe sdset 可能导致服务不可管理。
• 将程序安装在受保护目录，普通用户仅保留读取和执行权限；同步检查更新目录、插件目录、配置文件和 DLL 搜索路径。
• 为包含空格的 ImagePath 使用完整绝对路径并加双引号，同时保留参数在引号之外。
• 避免使用高权限域账户运行普通服务；优先使用专用低权限账户、虚拟服务账户或组托管服务账户。
• 限制服务账户交互式登录，并按实际业务收缩本地权限和网络访问范围。
• 对 HKLM\SYSTEM\CurrentControlSet\Services 下关键项配置变更监控，并将服务 ACL 纳入配置基线扫描。
• 修复后使用原低权限账户重新执行 AccessChk、icacls 和服务查询，确认权限确实被撤销，而不是仅修改了界面显示。

总结

Windows 服务弱权限的判断应形成完整证据链：低权限身份能够修改哪个对象、目标服务以什么账户运行、是否存在可控触发条件、系统防护是否阻断，以及测试过程是否可审计和回滚。

AccessChk 出现 SERVICE_CHANGE_CONFIG、WRITE_DAC 或 WRITE_OWNER 时，应按高风险权限边界问题继续排查；但最终定级仍需结合服务账户、文件 ACL、启动条件和防护策略。生产环境优先采用权限读取和服务描述变更等低影响方法，不应通过替换程序或强制重启来证明风险。

判断“服务弱权限”不能只看某一条 ACL，关键是能否闭合完整的提权链：低权限用户可控对象 → 高权限服务加载该对象 → 用户能够触发加载。

建议按下面几项确认：

1. 先确认服务运行身份和实际启动命令

   sc.exe qc 服务名
   powershell -NoProfile -Command "Get-CimInstance Win32_Service -Filter \"Name='服务名'\" | Format-List Name,StartName,State,StartMode,PathName"

   只有服务以 LocalSystem、LocalService、NetworkService 或其他高权限账号运行时，才有本地提权价值。普通用户身份运行的服务，即使可修改，通常也只是同权限代码执行。

2. 检查服务对象本身的权限

   sc.exe sdshow 服务名
   accesschk.exe -accepteula -nobanner -qv -c 服务名

   重点关注低权限主体（Users、Authenticated Users、Everyone）是否拥有以下权限：

   • SERVICE_CHANGE_CONFIG：可修改二进制路径或运行账号，通常可直接形成风险；
   • WRITE_DAC、WRITE_OWNER、GENERIC_ALL：可间接给自己授予修改配置权限；
   • SERVICE_START/SERVICE_STOP：单独存在通常不是提权，但会影响是否能立即触发。

   不要只根据 SDDL 中出现某个用户组就下结论，应结合当前测试账号的组成员关系和拒绝 ACE 判断有效权限：

   whoami /user
   whoami /groups
   whoami /priv

3. 检查可执行文件及其父目录是否可替换

   icacls "C:\Program Files\Vendor\App\service.exe"
   icacls "C:\Program Files\Vendor\App"
   accesschk.exe -accepteula -nobanner -qv "C:\Program Files\Vendor\App\service.exe"
   accesschk.exe -accepteula -nobanner -qv "C:\Program Files\Vendor\App"

   不能只看文件本身是否有写权限。父目录若允许创建、删除子项或重命名，攻击者仍可能通过“删除后替换”绕过文件 ACL。尤其要关注 Modify、Write、Delete、Delete child。

4. 检查服务注册表项

   reg.exe query "HKLM\SYSTEM\CurrentControlSet\Services\服务名"
   accesschk.exe -accepteula -nobanner -qv -k "HKLM\SYSTEM\CurrentControlSet\Services\服务名"

   如果低权限用户可以修改 ImagePath、ServiceDll、Parameters 等值，即使服务对象 ACL 正常，也可能在下次启动时加载可控程序或 DLL。具体读取哪些值要结合服务类型判断，特别是 svchost.exe 承载的 DLL 服务。

5. “未加引号路径”要结合候选路径可写性

   例如：

   C:\Program Files\Vendor App\service.exe -service

   可能产生 C:\Program.exe、C:\Program Files\Vendor.exe 等候选解析路径。但只有低权限用户能在对应位置创建文件时才构成风险。多数系统的磁盘根目录默认不可写，因此扫描器仅报“路径未加引号”并不足以证明可利用。

6. 确认触发条件

   即使路径或配置可控，如果攻击者既不能启动、停止服务，也无法等待重启或其他服务触发，风险等级需要相应下调。应确认：

   • 当前用户是否拥有启动/停止权限；
   • 服务是否自动启动；
   • 服务崩溃恢复策略是否会自动重启；
   • 是否存在计划任务、系统事件或依赖服务触发。

   sc.exe qfailure 服务名
   sc.exe enumdepend 服务名

实际定性时可以用下面的标准：

• 确认提权：普通用户可修改服务配置、二进制、关键目录或服务注册表项；服务以高权限账号运行；并且存在可行的启动、重启或系统重启路径。
• 潜在风险：前两项成立，但只能等待管理员操作或系统重启触发。
• 误报或低风险：仅有查询、启动、停止权限；目标路径实际不可写；或者服务本身不以更高权限运行。

验证时最好使用真实的非管理员测试账号，不要在生产环境直接替换服务文件。可以先用 ACL 有效权限检查和 Procmon 观察服务启动时实际访问的文件、DLL、注册表路径，再在隔离环境中做无害性复现。修复通常是收紧服务对象及注册表 ACL、移除目录继承的普通用户写权限，并对包含空格的可执行路径加双引号。