授权内网测试中普通域账号为何能访问服务器管理共享，如何定位权限来源与日志证据？

背景与问题

在一次已授权的内网权限边界测试中，测试人员使用普通域账号访问成员服务器的 \\server\C$，结果可以列出目录。账号表面上不属于 Domain Admins，也未被直接加入目标服务器的本地 Administrators 组。

需要确认三个问题：权限究竟来自哪里；成功访问是否等同于取得本地管理员权限；如何保留证据并修复越权配置。

这类问题不宜只看 Active Directory 用户属性。实际权限可能来自嵌套组、GPO Restricted Groups、组策略首选项、本地组历史残留、计算机管理平台或远程访问令牌过滤配置。

问题定位思路

建议从身份、授权、访问结果和审计日志四个层面分别取证，避免把“共享可连接”“目录可读取”和“具备完整管理员令牌”混为一谈。

• 身份：当前连接究竟使用了哪个账号和 Kerberos/NTLM 凭据。
• 授权：账号通过哪一层直接组或嵌套组进入目标服务器本地 Administrators。
• 访问：目标是默认管理共享 C$，还是另行配置但名称相似的共享。
• 日志：服务器是否记录 4624、4672、5140、5145 等事件，源地址是否与测试终端一致。

第一步：清理已有 SMB 会话并确认身份

Windows 会复用已有 SMB 会话。若测试终端之前使用管理员账号连接过同一服务器，再以普通账号验证时，结果很容易失真。先记录现状，再清理连接。

whoami /all
klist
net use
Get-SmbConnection | Select-Object ServerName,ShareName,UserName,Dialect

# 清理到指定服务器的会话，避免误用缓存凭据
net use \\server01\* /delete /y
klist purge

# 重新建立测试连接
net use \\server01\IPC$ /user:CONTOSO\testuser *
dir \\server01\C$

不要在命令行直接写密码，否则可能进入终端历史、脚本记录或进程采集日志。执行后再次检查 Get-SmbConnection 的 UserName 字段。如果同一客户端需要同时使用两个不同账号访问同一服务器，Windows 可能返回 1219 错误，此时应清理旧会话或换用隔离测试终端。

第二步：确认 C$ 的真实配置与本地组成员

在目标服务器上以经过批准的管理员会话检查共享和本地管理员组。默认 C$ 通常仅允许管理员访问，但应确认共享未被重建、权限未被人为放宽。

Get-SmbShare -Name 'C$' | Format-List Name,Path,Description,SpecialScope
Get-SmbShareAccess -Name 'C$'
Get-LocalGroupMember -Group 'Administrators' |
  Select-Object Name,ObjectClass,PrincipalSource

# 兼容旧系统
net localgroup Administrators
net share C$

重点记录本地 Administrators 中的域组，而不只是域用户。例如 CONTOSO\Server-Ops 看起来合理，但测试账号可能通过多层嵌套意外进入该组。

第三步：展开嵌套组并核对令牌

客户端执行 whoami /groups 可以看到当前登录令牌中的组 SID，但无法完整解释组关系来自何处。安装 Active Directory 模块的管理终端可执行递归成员查询。

Import-Module ActiveDirectory

# 查看用户的递归组成员关系
Get-ADPrincipalGroupMembership -Identity 'testuser' |
  Sort-Object Name |
  Select-Object Name,SamAccountName,GroupScope

# 如果目标本地管理员组包含某个域组，递归展开其成员
Get-ADGroupMember -Identity 'Server-Ops' -Recursive |
  Where-Object {$_.SamAccountName -eq 'testuser'} |
  Select-Object Name,SamAccountName,ObjectClass

Get-ADPrincipalGroupMembership 在跨域、信任关系或部分复杂嵌套环境中可能不完整，应同时结合用户令牌、目标组成员和域控制器查询结果。若刚调整过组成员关系，旧登录会话中的 Kerberos 票据仍可能保留旧权限，需要注销重新登录或清理票据后复测。

第四步：查明本地管理员成员由谁下发

如果成员服务器较多，且同一个异常域组普遍出现在本地 Administrators 中，优先检查 GPO，而不是逐台删除本地成员。

# 在目标服务器生成组策略结果
mkdir C:\Temp -ErrorAction SilentlyContinue
gpresult /scope computer /h C:\Temp\gpresult-computer.html

# 便于文本检索的结果
gpresult /scope computer /z > C:\Temp\gpresult-computer.txt

# 检查本机组策略应用日志
Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 200 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

重点检查两类配置：

• Restricted Groups：位于安全设置中，可能强制覆盖本地组成员。
• Group Policy Preferences 的 Local Users and Groups：可以对本地组执行添加、删除或替换操作。

同时查看计算机对象所在 OU、继承关系、强制链接、阻止继承以及安全筛选。只看默认域策略通常找不到真正来源。若环境使用 SCCM、Intune、Ansible、EDR 运维模块或自研基线平台，也应核对其任务记录。

第五步：用事件日志建立访问证据链

在目标服务器安全日志中，以测试时间窗、源 IP 和测试账号联合筛选。常见关键事件如下：

$start = (Get-Date).AddHours(-2)
$ids = 4624,4672,4732,4733,5140,5145

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = $start
} | Where-Object {
    $_.Message -match 'testuser|192\.0\.2\.25|\\\\\*\\C\$'
} | Select-Object TimeCreated,Id,MachineName,Message |
    Export-Csv C:\Temp\smb-access-evidence.csv -NoTypeInformation -Encoding UTF8

上述 Message 文本匹配适合现场快速排查，但不同系统语言会影响字段名称。长期检测应由 SIEM 解析 XML 字段，不要依赖本地化文本。还需要将 4624 的 Logon ID 与 4672、5140、5145 关联，确认它们属于同一登录会话。

审计未记录 5145 时如何处理

5145 依赖“审核详细文件共享”，仅启用基础文件共享审核通常不够。可先检查当前策略，不建议未经变更审批直接修改生产域策略。

auditpol /get /subcategory:'File Share'
auditpol /get /subcategory:'Detailed File Share'

# 经审批后启用成功与失败审核
AuditPol /set /subcategory:'File Share' /success:enable /failure:enable
AuditPol /set /subcategory:'Detailed File Share' /success:enable /failure:enable

详细文件共享事件量可能较大。建议先在服务器 OU 的小范围试点，观察日志增长和转发链路容量，再决定是否全量启用。对域控制器、文件服务器和关键管理服务器可设置更长的集中留存周期。

容易误判的情况

• 客户端仍保留旧管理员 SMB 会话，普通账号测试结果实际复用了管理员凭据。
• 账号刚被移出管理员组，但当前登录令牌或 Kerberos 票据尚未刷新。
• 访问的是自定义共享而非默认 C$，共享权限允许读取，但 NTFS 权限限制了实际文件访问。
• 仅凭 4672 判断账号是管理员。该事件表示登录获得特定敏感特权，应结合令牌和组成员关系分析。
• 将 UAC 远程限制视为主要防护。域账号已进入本地 Administrators 时，不能依赖令牌过滤替代权限治理。

风险与修复建议

• 从权限源头修复：若由 GPO 下发，应修改对应 GPO 和安全筛选，避免手工删除后再次被策略加回。
• 拆分运维角色：工作站、本地服务器、域控制器分别使用不同管理组，不复用宽泛的 Server-Ops 组。
• 清理嵌套组：对进入本地 Administrators 的域组建立递归成员基线，定期比较新增成员。
• 落实最小权限：普通业务账号不应同时持有服务器管理权限，管理员使用独立账号并限制登录范围。
• 保护本地管理员凭据：使用 Windows LAPS 管理本地管理员密码，避免多台主机共用固定密码。
• 集中日志：转发 4624、4672、4732、4733、5140、5145，并对普通账号访问管理共享、非管理终端发起管理共享访问建立告警。
• 修复后复测：清理 SMB 会话和票据，重新登录，再验证 C$ 访问失败，同时确认正常运维账号未受影响。

验收标准

修复不应只以“命令返回拒绝访问”为结论。建议同时满足：普通账号不再出现在任何授权链路中；清理会话后无法访问 C$；策略刷新后成员不会恢复；安全日志能够记录失败访问；合法运维账号仍可按审批范围操作。

总结

普通域账号可以访问管理共享时，最常见原因不是单一漏洞，而是缓存会话、嵌套组和集中配置共同造成的权限边界失控。可靠的排查顺序是先确认实际身份，再追踪本地组和域组授权链，随后定位 GPO 或管理平台来源，最后用服务器日志闭环验证。修复应落在权限源头，并通过清理会话后的复测和日志告警确认效果。

先确认“能访问”的具体含义。仅能连接 IPC$、枚举到共享名，不等于能读取 ADMIN$/C$；应实际测试目录读取和文件创建，并清理客户端已有 SMB 会话，避免复用了其他凭据：

net use \\server\* /delete /y
klist purge

net use \\server\C$ /user:DOMAIN\testuser *
dir \\server\C$\Windows
echo test > \\server\C$\Windows\Temp\share-test.txt

默认情况下，ADMIN$ 和盘符管理共享的共享权限主要授予本机 Administrators。普通域账号能够实际读写，优先查它是否通过嵌套组、GPO 或运维软件被加入了服务器本地管理员组，而不是只看 AD 中的直接组成员关系。

在目标服务器执行：

Get-LocalGroupMember -Group Administrators |
    Format-Table Name,PrincipalSource,ObjectClass -Auto

net localgroup Administrators

Get-SmbShareAccess -Name 'C$'
Get-SmbShareAccess -Name 'ADMIN$'

icacls C:\
icacls C:\Windows

如果本地管理员组中存在域组，再递归展开。不要只用 whoami /groups 判断，因为那反映的是当前登录服务器的令牌，不一定等同于测试账号通过 SMB 建立的网络登录令牌：

Get-ADGroupMember '疑似域组' -Recursive |
    Where-Object SamAccountName -eq 'testuser'

Get-ADPrincipalGroupMembership testuser |
    Select-Object Name,DistinguishedName

常见权限来源是“受限制的组”、组策略首选项中的“本地用户和组”，或者配置管理平台定期回填成员。可先看目标服务器的策略结果：

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

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership" /s

在报告中重点找：

• Computer Configuration\Windows Settings\Security Settings\Restricted Groups
• Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups
• 启动脚本、计划任务或配置管理程序执行的 net localgroup/Add-LocalGroupMember

还要排除凭据混淆：客户端可能已有到同一服务器的连接、使用了保存凭据，或者通过别名/IP 建立了另一条会话。客户端检查：

net use
cmdkey /list
Get-SmbConnection | Format-Table ServerName,ShareName,UserName,Dialect

服务端可直接查看当前 SMB 会话实际使用的账号：

Get-SmbSession |
    Select-Object ClientComputerName,ClientUserName,SessionId,NumOpens

Get-SmbOpenFile |
    Select-Object ClientComputerName,ClientUserName,ShareRelativePath

取证时建议关联安全日志中的同一个 Logon ID：

• 4624：成功登录，通常为 Logon Type 3，确认 Account Name、Source Network Address、Authentication Package。
• 4672：新登录被授予敏感特权，可辅助判断是否获得管理员级令牌。
• 5140：访问了哪个网络共享。
• 5145：访问的相对路径、请求权限以及访问检查结果，定位文件级证据最有用。

$start = (Get-Date).AddMinutes(-30)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624,4672,5140,5145
    StartTime = $start
} | Select-Object TimeCreated,Id,Message |
    Format-List

如果没有 5145，需要先启用“详细文件共享”审核；生产环境建议短时、定向开启，避免日志量过大：

auditpol /get /subcategory:"File Share"
auditpol /get /subcategory:"Detailed File Share"

auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable

另外，LocalAccountTokenFilterPolicy 主要影响本地账号的远程 UAC 令牌过滤，并不能解释普通域账号凭空获得管理共享权限；如果测试账号是域账号，应优先沿“本地 Administrators → 嵌套域组 → GPO/自动化配置”这条链查。最终证据最好同时保留：客户端实际命令、服务端 SMB 会话、4624 的源地址与 Logon ID、5140/5145 的共享及路径，以及对应 GPO 报告。