授权渗透实战：定位并验证域环境中的本地管理员权限扩散链路

背景

在 Windows 域内渗透中，常见风险并不是单台主机存在本地管理员账号，而是同一个域组、运维账号或服务账号通过 GPO、启动脚本和终端管理平台被批量加入多台主机的本地 Administrators 组。一旦其中一组凭据泄露，攻击者可能沿着 WinRM、WMI、计划任务或远程服务形成横向移动链路。

本文讨论一个授权测试场景：测试账号已经通过正常流程取得某台运维终端的登录权限，需要确认其本地管理员权限是否被错误扩散到服务器网段。验证重点是权限边界、可达范围和日志证据，不进行凭据抓取，也不关闭终端防护。

所有命令应仅在书面授权范围内执行。验证前应明确允许访问的网段、账号、时间窗口和测试主机，禁止使用生产数据执行写入测试。

问题定位

先区分三个问题：当前账号是否真的拥有本地管理员权限、权限来自本机配置还是域策略、相同主体是否出现在其他主机。仅看到账号属于某个域组，并不能直接说明它能管理目标主机。

第一步：确认当前令牌和权限来源

在已授权终端上检查当前身份、组 SID 和令牌特权。Windows 的管理员组 SID 为 S-1-5-32-544，输出中出现该 SID 只能证明组成员关系；如果 UAC 过滤生效，还要结合令牌状态判断当前进程是否已提升。

whoami
whoami /groups
whoami /priv

$principal = New-Object Security.Principal.WindowsPrincipal(
    [Security.Principal.WindowsIdentity]::GetCurrent()
)
$principal.IsInRole(
    [Security.Principal.WindowsBuiltInRole]::Administrator
)

随后读取本地管理员组成员，记录对象类型和来源。优先使用 Get-LocalGroupMember；旧系统可以使用 net localgroup 作为兼容方案。

Get-LocalGroupMember -Group Administrators |
    Select-Object Name,ObjectClass,PrincipalSource,SID

net localgroup Administrators

如果成员包含域组，例如 CORP\Workstation-Admins，应继续查询该组的直接成员和嵌套成员。递归查询容易产生大量结果，建议导出后与授权账号清单比对。

Import-Module ActiveDirectory

Get-ADGroupMember -Identity 'Workstation-Admins' -Recursive |
    Select-Object Name,SamAccountName,ObjectClass,DistinguishedName |
    Export-Csv .\workstation-admins.csv -NoTypeInformation -Encoding UTF8

第二步：判断权限是否由 GPO 下发

本地管理员组中的域主体可能来自 Restricted Groups，也可能来自 Group Policy Preferences 的 Local Users and Groups。两者都应检查，否则容易把持续下发的配置误判为人工添加。

先生成当前计算机的策略结果报告：

mkdir C:\Temp -ErrorAction SilentlyContinue
gpresult /scope computer /h C:\Temp\computer-gpo.html
gpresult /scope computer /z > C:\Temp\computer-gpo.txt

重点查看“受限制的组”和“本地用户和组”配置。具备读取 SYSVOL 权限时，还可以在域策略目录中定位相关配置文件。以下命令只执行读取，不修改策略：

$domain = (Get-ADDomain).DNSRoot
$sysvol = "\\$domain\SYSVOL\$domain\Policies"

Get-ChildItem $sysvol -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -in @('GptTmpl.inf','Groups.xml') } |
    Select-String -Pattern 'Administrators|S-1-5-32-544' |
    Select-Object Path,LineNumber,Line

GptTmpl.inf 通常对应 Restricted Groups；Groups.xml 通常对应组策略首选项。发现配置后，应记录策略 GUID，并使用 Group Policy 模块反查显示名称和链接位置：

Import-Module GroupPolicy
Get-GPO -All |
    Select-Object DisplayName,Id,GpoStatus,ModificationTime

Get-GPInheritance -Target 'OU=Workstations,DC=corp,DC=example,DC=com'

判断风险时不能只看 GPO 内容，还要确认它链接到了哪个 OU、是否启用强制、是否存在安全筛选，以及目标计算机账户是否具备 Read 和 Apply Group Policy 权限。

第三步：枚举可能受影响的主机

不要直接对整个域进行端口扫描。更稳妥的方法是先从 AD 获取授权 OU 内的计算机清单，再以低并发方式检查 WinRM、SMB 或 RPC 是否可达。示例只针对明确授权的工作站 OU：

$targets = Get-ADComputer \
    -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' \
    -Filter 'Enabled -eq $true' \
    -Properties DNSHostName,OperatingSystem,LastLogonDate |
    Where-Object DNSHostName |
    Select-Object -ExpandProperty DNSHostName

$results = foreach ($hostName in $targets) {
    $winrm = Test-NetConnection $hostName -Port 5985 \
        -InformationLevel Quiet -WarningAction SilentlyContinue
    $smb = Test-NetConnection $hostName -Port 445 \
        -InformationLevel Quiet -WarningAction SilentlyContinue
    [pscustomobject]@{
        Host  = $hostName
        WinRM = $winrm
        SMB   = $smb
    }
    Start-Sleep -Milliseconds 300
}

$results | Export-Csv .\reachable-hosts.csv -NoTypeInformation -Encoding UTF8

端口可达不等于权限成立。下一步应使用专门创建的测试账号进行最小化验证，避免拿高权限账号测试后得出错误结论。

第四步：执行低影响权限验证

优先使用 WinRM 执行只读命令。它能明确区分网络不可达、身份认证失败和远程授权失败，并会产生相对清晰的事件日志。不要在验证阶段创建服务、计划任务或远程用户。

$cred = Get-Credential 'CORP\pt-test'
$session = New-PSSession \
    -ComputerName 'ws-023.corp.example.com' \
    -Credential $cred \
    -Authentication Kerberos

Invoke-Command -Session $session -ScriptBlock {
    [pscustomobject]@{
        ComputerName = $env:COMPUTERNAME
        Identity     = [Security.Principal.WindowsIdentity]::GetCurrent().Name
        IsAdmin      = (New-Object Security.Principal.WindowsPrincipal(
            [Security.Principal.WindowsIdentity]::GetCurrent()
        )).IsInRole(
            [Security.Principal.WindowsBuiltInRole]::Administrator
        )
    }
}

Remove-PSSession $session

如果业务要求验证管理员写权限，可在目标主机约定的测试目录创建随机文件并立即删除，不应写入系统目录、服务配置或注册表启动项。写入动作必须提前获得批准，并保留文件哈希和操作时间。

Invoke-Command -ComputerName 'ws-023.corp.example.com' \
    -Credential $cred -Authentication Kerberos -ScriptBlock {
        $path = 'C:\Temp\authorized-pentest-proof.txt'
        $content = 'ticket=PT-2025-017; no-sensitive-data'
        Set-Content -Path $path -Value $content -Encoding ASCII
        $hash = Get-FileHash $path -Algorithm SHA256
        Remove-Item $path -Force
        $hash
    }

第五步：核对日志留痕

权限验证需要同时给出主机侧和域控侧证据。建议统一记录测试机 IP、目标主机、测试账号、开始与结束时间，并校准时区。

目标主机上可以按测试时间窗口导出事件。生产环境不要使用过宽的时间范围，否则查询可能造成额外负载。

$start = (Get-Date).AddMinutes(-30)
$ids = 4624,4625,4672,4688

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = $start
} -ErrorAction Stop |
    Select-Object TimeCreated,Id,MachineName,Message |
    Export-Csv C:\Temp\pentest-events.csv \
        -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-WinRM/Operational'
    StartTime = $start
} |
    Select-Object TimeCreated,Id,Message

技术分析

确认权限扩散链路时，应至少形成“主体、授权来源、作用范围、可用协议、实际验证、日志证据”六项闭环。例如：测试账号属于嵌套域组，域组由某 GPO 加入本地 Administrators，GPO 链接到工作站 OU，目标主机开放 WinRM，使用 Kerberos 成功建立远程会话，目标主机和域控均存在对应事件。

如果只有端口扫描结果，不能证明横向移动风险；如果只有本地管理员组截图，也不能证明策略影响范围；如果通过 NTLM 回退才成功，还应单独检查 Kerberos 配置、SPN、名称解析和远程管理策略。

风险判断

• 高风险：同一常用域账号或大范围域组在大量终端、服务器上拥有本地管理员权限，且允许远程管理。
• 高风险：工作站管理员组同时覆盖服务器 OU，导致终端失陷后可以跨安全区移动。
• 中风险：权限范围较小，但账号可交互登录、口令长期不轮换，或者缺少登录来源限制。
• 中风险：权限配置合理，但 4624、4672、4688 或 WinRM 日志未集中留存，无法追溯远程操作。
• 低风险：使用独立管理账号，按设备分组授权，限制管理来源，并对高权限登录进行集中告警。

修复建议

• 拆分工作站、服务器和关键业务系统的管理员组，禁止同一高权限主体跨安全区复用。
• 从 GPO 中移除 Domain Users、Authenticated Users、通用运维组等过宽主体，只保留职责明确的安全组。
• 采用 Windows LAPS 管理本地管理员密码，避免多台主机共享相同本地凭据。
• 通过防火墙限制 5985、5986、445、135 等管理端口，仅允许管理网段和跳板机访问。
• 为运维账号设置“拒绝本地登录”或“拒绝通过远程桌面服务登录”等边界，按实际管理方式放行必要权限。
• 优先使用 Kerberos；排查并减少 NTLM 回退，同时监控异常的服务票据申请和跨主机管理行为。
• 启用进程创建审计并记录命令行，集中采集 Security、PowerShell 和 WinRM 日志，设置与测试行为对应的告警规则。
• 修复后重新执行组成员、GPO 作用范围和远程会话验证，确认不是仅在单台主机手工删除成员后被策略再次写回。

总结

域内本地管理员扩散不能只靠扫描或组成员列表判断。有效的授权渗透验证应从账号令牌开始，追溯 GPO 或本机配置，限定主机范围，使用低影响方式证明远程权限，并以主机和域控日志完成取证闭环。最终报告应明确风险主体、受影响资产、复现条件和策略级修复位置，避免只给出“加强权限管理”之类无法落地的结论。

这类权限扩散链路建议不要只看“谁当前属于本地 Administrators”，还要同时追溯成员来源和登录路径。域环境里最常见的链路是：域组被 GPO 下发到多台主机的本地管理员组，某个普通账号又通过嵌套组间接进入该域组，随后其凭据在运维跳板机或服务器上重复使用。

可以先在目标主机上确认本地管理员成员，并解析成员 SID，避免被重命名账号或同名组干扰：

Get-LocalGroupMember -Group 'Administrators' |
    Select-Object Name,ObjectClass,PrincipalSource,SID

Get-CimInstance Win32_GroupUser |
    Where-Object { $_.GroupComponent -match 'SID="S-1-5-32-544"' } |
    Select-Object GroupComponent,PartComponent

如果成员来自域组，继续在域控或安装了 RSAT 的管理机上展开嵌套关系：

Get-ADGroupMember -Identity '目标域组' -Recursive |
    Select-Object Name,SamAccountName,ObjectClass,DistinguishedName

Get-ADPrincipalGroupMembership -Identity '可疑账号' |
    Select-Object Name,GroupScope,DistinguishedName

接下来检查该成员关系是否由 GPO 建立，重点看 Restricted Groups，以及组策略首选项中的 Local Users and Groups：

Get-GPOReport -All -ReportType Xml -Path .\all-gpo.xml

Select-String -Path .\all-gpo.xml `
    -Pattern 'RestrictedGroups|LocalUsersAndGroups|S-1-5-32-544|Administrators'

还应核对 GPO 的链接 OU、启用状态、安全筛选和 WMI Filter。只找到配置内容但没确认实际作用范围，容易误判扩散面。客户端可用以下命令验证最终生效策略：

gpresult /scope computer /h C:\Windows\Temp\computer-gpo.html
gpresult /r /scope computer

验证链路时建议优先使用日志证据，而不是直接进行凭据提取。可围绕以下事件关联账号、源地址和目标主机：

• 4624：成功登录，重点关注登录类型 3、10；
• 4672：分配敏感特权；
• 4732、4733：本地安全组成员增删；
• 4728、4729、4756、4757：域组成员变更；
• 4648：使用显式凭据；
• 7045：新服务安装，可辅助识别远程管理行为。

$start = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624,4648,4672,4732,4733
    StartTime = $start
} | Select-Object TimeCreated,Id,MachineName,Message |
    Export-Csv .\privilege-chain-events.csv -NoTypeInformation -Encoding UTF8

为了把“具备管理员权限”和“实际形成横向路径”区分开，可以建立三类节点：账号、域组、主机；边分别记录组嵌套、本地管理员成员关系和交互式/远程登录记录。只有同时存在“账号经组关系获得主机管理员权限”以及“该账号在其他主机出现有效登录”的情况，才应标记为已验证链路。

最后建议保存验证前后的证据：主机名、SID、组成员来源、GPO GUID、策略链接位置、事件时间和源 IP。修复时优先处理嵌套组和 GPO 作用范围，避免只在单机删除成员后被下一次组策略刷新重新加回。