授权渗透攻防实战：从域用户落点到 Windows 内网权限边界验证

背景

在 Windows 域环境的授权渗透测试中，拿到普通域用户并不等于可以直接横向移动。更有价值的工作，是确认账号暴露面、主机管理边界、SMB 安全配置和委派关系，并用最小化验证证明风险。本案例假设测试方已获得一个低权限域账号，目标是识别错误授权形成的攻击链，同时控制访问范围和日志影响。

以下操作仅适用于已取得书面授权的测试环境。执行前应明确测试账号、源地址、目标网段、允许访问的主机以及禁止触碰的业务系统。

问题定位

初始信息只有域账号 corp\audit.user 和一台接入办公网的测试终端。此时不建议直接进行全网端口扫描或批量认证，而应先回答三个问题：当前账号属于哪些组、哪些主机允许该账号远程登录、是否存在能够把普通域权限放大的错误配置。

在域终端上先采集本机与域上下文：

whoami /all
whoami /groups
set USERDOMAIN
set LOGONSERVER
ipconfig /all
nltest /dsgetdc:corp.example
net user audit.user /domain

重点记录域 SID、组成员关系、登录服务器、DNS 后缀和域控制器地址。若 whoami 输出中出现服务器运维组、备份操作员或远程管理相关组，应先与甲方确认这是否属于预期授权，避免把测试账号本身的特殊权限误判为漏洞。

技术分析

普通域用户常见的权限扩展入口主要来自三类配置：第一类是主机本地管理员组错误纳入了宽泛域组；第二类是共享目录或服务账号文件对普通用户开放；第三类是 Active Directory 对象权限配置不当，例如低权限主体可以修改某个组成员或计算机对象属性。

验证时应坚持“只读枚举优先、单点认证验证、禁止批量喷洒”。尤其不要用同一账号快速访问大量主机，否则既可能触发锁定策略，也会污染域控和终端日志。

操作步骤一：限定范围发现服务

仅对授权清单中的地址进行必要端口探测。Windows 横向边界通常关注 SMB、RPC、WinRM 和远程桌面，不需要默认执行全端口及版本脚本。

# targets.txt 必须来自授权资产清单
nmap -Pn -n -T3 --max-rate 50 \
  -p 135,139,445,3389,5985,5986 \
  -iL targets.txt -oA windows-boundary

如果资产数量较大，应分批执行，并把源 IP、开始时间、结束时间和输出文件哈希写入测试记录。445 端口开放只代表 SMB 可达，不代表当前账号具备管理权限。

操作步骤二：检查 SMB 签名与共享边界

SMB 签名未强制可能扩大中继类攻击的条件，但验证阶段不必实际执行中继。可以先通过协议协商确认配置，再结合网络分区和 NTLM 使用情况给出风险判断。

nmap -Pn -n -p445 --script smb2-security-mode \
  -iL targets.txt -oN smb-signing.txt

# 单台主机、单个授权账号的共享访问验证
smbclient -L //10.20.30.15 -U 'CORP/audit.user' --option='client min protocol=SMB2'

结果中若显示 message signing enabled but not required，说明服务端支持签名但没有强制。此项不能脱离场景直接定为高危：还应确认是否允许 NTLM、攻击者能否处于可中继网络位置，以及目标服务是否接受相关认证。

共享权限检查应区分“能列目录”“能读取文件”和“能写入文件”。在生产环境中不要上传可执行文件。若必须证明写权限，可在甲方确认后创建零危害标记文件并立即删除：

smbclient //10.20.30.15/Deploy -U 'CORP/audit.user'
# 交互环境中仅验证指定测试目录
ls
put authorized-write-test.txt
rm authorized-write-test.txt

操作步骤三：验证远程管理权限

WinRM 可达不代表账号可以建立远程会话。建议使用系统自带命令做单点验证，并避免执行改变系统状态的指令。

# Windows PowerShell，仅针对授权主机
Test-NetConnection srv-app-01.corp.example -Port 5985
Test-WSMan srv-app-01.corp.example

# 已确认允许认证测试后，执行无状态身份查询
$cred = Get-Credential 'CORP\audit.user'
Invoke-Command -ComputerName srv-app-01.corp.example \
  -Credential $cred -ScriptBlock { whoami; hostname }

如果普通业务账号能够通过 WinRM 登录服务器，需要继续判断它是 Remote Management Users 成员，还是通过本地 Administrators、组策略或嵌套域组获得权限。不要仅凭远程命令执行成功就断言“域权限提升”。

操作步骤四：核对本地管理员来源

在获得甲方许可并已具备目标主机查询权限的前提下，可读取本地组成员。核心是追溯成员来源，而不是继续执行破坏性操作。

Get-LocalGroupMember -Group 'Administrators'
Get-LocalGroupMember -Group 'Remote Management Users'

# 域侧核对可疑组及嵌套关系
Get-ADGroupMember -Identity 'Server-Operators-App' -Recursive
Get-ADPrincipalGroupMembership -Identity 'audit.user' | Select-Object Name

典型错误是将 Domain Users、部门全员组或可由普通人员自助加入的组放入服务器本地管理员组。若使用组策略下发本地组成员，还应检查对应 GPO 的作用范围、继承关系及修改权限。

操作步骤五：检查 Active Directory 对象权限

对象 ACL 是容易被忽略的权限边界。低权限用户如果对高权限组拥有 WriteProperty、WriteDacl、WriteOwner 或 GenericAll，就可能形成明确的权限扩展路径。生产环境应先导出 ACL，不要直接修改对象。

Import-Module ActiveDirectory

$dn = (Get-ADGroup 'Server-Operators-App').DistinguishedName
(Get-Acl ('AD:\' + $dn)).Access |
  Select-Object IdentityReference,ActiveDirectoryRights,AccessControlType,ObjectType,IsInherited |
  Format-Table -AutoSize

分析时需要区分继承权限和显式权限，并解析 ObjectType GUID。仅出现 WriteProperty 并不一定意味着可以修改所有属性；它可能只对应某个受限属性集。报告中应写清主体、目标对象、权限类型、是否继承以及可能修改的具体属性。

日志留痕与证据关联

权限验证必须能从防守侧复盘。建议测试方保存命令时间戳、源 IP、目标主机和操作结果，同时让蓝队检查以下日志：

若 5136 或组成员变更事件未开启，应在修复阶段补充高级审核策略。日志应集中发送至独立平台，避免只保留在被测主机本地。

风险判定

风险等级应根据完整链路判断，而不是按单一配置项打分。例如，“普通域用户可写部署共享”本身可能只是中风险；如果该共享中的脚本会被服务器以 SYSTEM 身份定时执行，则应提升等级。报告证据应包含共享 ACL、文件系统 ACL、调用任务身份、执行周期和最小化验证结果。

• 低权限账号可远程管理关键服务器：通常属于高风险权限边界失效。
• 低权限主体可修改高权限组 ACL 或成员：通常属于高风险域权限扩展。
• SMB 未强制签名但不存在可行认证链路：应结合环境评估，不宜机械定高危。
• 业务共享可写但无高权限消费路径：主要是数据完整性和勒索传播风险。

修复建议

• 清理服务器本地 Administrators 和 Remote Management Users 中的宽泛域组，改用按职责拆分的专用安全组。
• 通过组策略强制 SMB 服务端和客户端签名；逐步限制 NTLM，启用前先审计遗留设备兼容性。
• 共享权限与 NTFS 权限同时收敛，部署目录采用只读发布流程，禁止普通用户直接写入高权限任务会消费的位置。
• 审计高价值组、计算机对象和 GPO 的 ACL，移除不必要的 WriteDacl、WriteOwner、GenericWrite 与 GenericAll。
• 管理账号与办公账号分离，对服务器管理启用专用跳板机、网络隔离和多因素认证。
• 开启进程创建、PowerShell、目录服务变更和组管理审核，并对异常远程登录及成员变更建立告警。

复测方法

修复后使用原低权限账号重复相同的只读步骤，预期结果应为：无法建立 WinRM 管理会话、不能写入部署共享、不再属于任何间接管理组、对敏感 AD 对象仅保留读取权限。复测不应更换成权限更高的账号，否则无法证明原始攻击链已被切断。

总结

内网渗透攻防的重点不是“扫到多少端口”，而是把身份、主机、目录权限和日志证据串成可复现的权限链。以低权限账号为起点，限定资产范围，先做只读枚举，再进行单点最小化验证，既能证明真实风险，也便于蓝队定位日志并完成针对性修复。

这个场景里，建议把“域用户落点”到“权限边界验证”拆成身份、主机、域对象、凭据四条证据链。重点不是拿到一次高权限会话，而是确认权限从哪里继承、在哪台机器生效，以及撤销哪项配置可以切断路径。

落点后先固定基线，避免把本机权限误判成域权限：

whoami /all
whoami /groups
whoami /priv
hostname
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Domain"
nltest /dsgetdc:%USERDNSDOMAIN%
gpresult /scope computer /r
gpresult /scope user /r

随后验证横向访问边界，但不要只用“端口开放”作为结论。应分别记录网络可达、身份认证和资源授权结果：

Test-NetConnection FILE01 -Port 445
Test-NetConnection APP01 -Port 5985
dir \\FILE01\IPC$
dir \\FILE01\C$
net use \\FILE01\IPC$ /user:DOMAIN\user *

IPC$ 成功只能说明认证通过，不能证明具备远程管理权限；C$、SCM、WinRM、计划任务等管理面需要分别验证。测试失败时也要区分防火墙、服务未启用、UAC 远程限制和 ACL 拒绝，避免得出错误结论。

域侧建议优先查组嵌套、主机本地管理员来源和 AD 对象 ACL。具备 RSAT 时可以直接留证：

Get-ADPrincipalGroupMembership $env:USERNAME |
  Select-Object Name,DistinguishedName

Get-ADGroupMember "目标组" -Recursive |
  Select-Object Name,ObjectClass,DistinguishedName

Get-ADComputer "WS01" -Properties msDS-AllowedToDelegateTo,
  PrincipalsAllowedToDelegateToAccount |
  Format-List Name,msDS-AllowedToDelegateTo,
  PrincipalsAllowedToDelegateToAccount

(Get-Acl "AD:\CN=目标对象,OU=Servers,DC=example,DC=local").Access |
  Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteOwner"
  } |
  Select-Object IdentityReference,ActiveDirectoryRights,
    AccessControlType,IsInherited

如果发现高风险 ACE，报告里要写清楚主体、目标、权限类型、是否继承及继承源。尤其要区分“当前可利用”与“理论路径”：例如写组成员、写 SPN、写 RBCD 属性、接管对象所有者，前置条件和影响并不相同。

主机侧则应核对本地组和特权分配的真实来源：

Get-LocalGroupMember Administrators
net localgroup Administrators
secedit /export /cfg %TEMP%\secpol.cfg
findstr /I "SeDebugPrivilege SeImpersonatePrivilege SeBackupPrivilege" %TEMP%\secpol.cfg

最后建议为每条路径保留“最小验证”原则：能通过只读查询、ACL 读取或访问受控测试文件证明的，就不要创建域管理员、修改生产 GPO 或导出真实凭据。必须实施写操作时，提前记录原值、设置回滚命令和停止条件，并在结束后复查事件日志。域对象变更可重点关联 4728、4732、4756、5136，登录与特权使用可关注 4624、4672、4688。这样形成的结果更容易复现，也方便防守方定位真正需要修复的权限边界。