渗透攻防实战：授权内网测试中从凭据暴露到权限边界验证的完整链路

本文以一次经过书面授权的 Windows 域内渗透测试为例，讨论如何从一台普通办公终端出发，验证凭据暴露、SMB/WinRM 管理面暴露以及域权限边界是否存在缺口。重点不在“拿下多少主机”，而在于还原攻击路径、保留可审计证据，并给出能够落地的修复方案。

一、测试背景与边界

测试环境为典型的 AD 域：办公网段为 10.20.10.0/24，服务器网段为 10.20.20.0/24，域控为 DC01.corp.example.local。测试账号为普通域用户 audit_user，不允许修改域对象、不允许持久化、不允许破坏性操作。

• 只验证授权网段和授权账号，禁止扫描生产网段之外的地址。
• 发现高权限凭据后只做最小化证明，例如读取目标主机名和当前用户，不执行批量导出。
• 所有命令、时间戳、源地址和结果写入测试记录，便于蓝队复核。

二、问题定位：先确认网络暴露，再确认权限关系

内网渗透中常见的误区是直接寻找“高危漏洞”。实际风险往往来自多个低危条件叠加：普通终端可以访问管理端口，脚本或配置文件中残留服务账号密码，服务账号又被赋予了过大的本地管理员或域权限。因此第一步应当确认可达面，而不是立即进行利用。

# 仅对授权网段做端口确认，避免大范围扫描
nmap -Pn -n -p 445,5985,5986,3389 --open 10.20.10.0/24 -oA authorized_mgmt_ports

# 在已授权的 Windows 测试主机上确认当前身份和域信息
whoami /all
set USERDNSDOMAIN
nltest /dsgetdc:corp.example.local

# 查看当前主机到指定服务器的 SMB/WinRM 连通性
Test-NetConnection FS01.corp.example.local -Port 445
Test-NetConnection APP01.corp.example.local -Port 5985

端口开放本身不代表漏洞，但它决定了后续权限边界是否容易被跨越。对于普通办公终端，若能够直接访问大量服务器的 445、5985 或 3389 端口，应进一步核查网络隔离和管理面访问控制。

三、凭据暴露的验证方法

在获得授权的测试终端上，优先检查常见的明文凭据来源：登录脚本、部署脚本、备份配置、计划任务参数和应用配置文件。不要使用全盘递归读取方式影响终端性能，也不要把发现的密码直接写入报告正文。

# 示例：在授权目录内查找疑似配置文件
Get-ChildItem -Path C:\Scripts,C:\Deploy,C:\inetpub\wwwroot -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Extension -in '.ps1','.bat','.cmd','.config','.xml','.ini','.yml' } |
  Select-Object -ExpandProperty FullName

# 对指定目录做关键词定位，输出文件名和行号，避免直接导出完整文件
Select-String -Path C:\Scripts\* -Pattern 'password|passwd|pwd|token|connectionString' `
  -CaseSensitive:$false -ErrorAction SilentlyContinue |
  Select-Object Path,LineNumber,Line

# 核查当前用户可见的计划任务及其执行账户
schtasks /query /fo LIST /v | findstr /i "TaskName Run As User Task To Run"

验证到疑似密码后，不应立即尝试登录大量主机。可以先通过单一目标、低权限读取操作确认其有效性，例如读取目标主机名、当前用户和域名。若账号属于服务账号，应额外确认它是否被错误加入了本地 Administrators、Account Operators 或其他高权限组。

四、权限边界分析

对于已确认的服务账号，重点检查三类关系：

• 账号是否在多台服务器上复用，尤其是应用服务器与文件服务器之间。
• 账号是否具备远程登录、远程管理或本地管理员权限。
• 账号是否拥有不必要的域对象修改权限，例如对计算机对象、组对象或组策略对象具有写入权限。

在域控或授权的管理主机上，可使用只读查询确认组成员关系；普通测试终端则只验证自身可见范围：

# 查询某个账号的域组关系，要求当前账号具有相应目录读取权限
net user svc_backup /domain

# 查询目标主机上的本地管理员成员，仅在授权主机上执行
net localgroup administrators

# 查询当前会话、共享连接和已建立的管理通道
quser
net use
cmdkey /list

# 检查 WinRM 是否启用以及允许的来源配置
winrm get winrm/config/service
winrm get winrm/config/client

如果发现普通域用户能够通过 WinRM 登录到服务器，或者服务账号在多台主机上拥有本地管理员权限，应将其描述为“权限边界设计问题”，而不仅是“密码泄露”。密码轮换只能解决当前凭据泄露，不能消除过度授权和横向复用。

五、日志留痕与蓝队复核

授权验证过程中应同步观察日志，确认每一步操作在防守侧是否可见。重点事件包括：

• 域控制器安全日志 4624、4625：成功和失败的登录，关注 Logon Type 3、8、10 以及异常源地址。
• 4672：特殊权限分配，常见于高权限账号登录。
• 4688：进程创建，需确认是否启用了命令行参数记录。
• WinRM 相关日志：Microsoft-Windows-WinRM/Operational。
• PowerShell 4103、4104：模块日志和脚本块日志。
• SMB 服务端日志：Microsoft-Windows-SMBServer/Operational。

# 在授权 Windows 主机上按时间窗口筛选登录和进程事件
$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4672,4688; StartTime=$start} |
  Select-Object TimeCreated,Id,MachineName,Message

# 查看 WinRM 操作日志
Get-WinEvent -LogName 'Microsoft-Windows-WinRM/Operational' -MaxEvents 50 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

# 查看 PowerShell 脚本块日志是否启用
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 50 |
  Where-Object {$_.Id -in 4103,4104} |
  Select-Object TimeCreated,Id,Message

测试报告中建议建立“动作—日志—结论”对应表。例如：使用普通账号访问 APP01 的 WinRM，源地址为 10.20.10.25，目标地址为 10.20.20.15，防守侧应能在 APP01 的 4624 和 WinRM Operational 日志中关联到该行为。若只能看到登录成功，无法看到执行的命令，则说明进程审计或 PowerShell 日志仍不完整。

六、常见误判与修复建议

七、报告结论应如何落地

一个合格的渗透攻防结论应描述完整链路：起点账号权限、可达的管理面、凭据暴露位置、实际验证的目标、能够证明的权限范围、对应日志以及修复后的复测结果。不要只写“可横向移动”或“存在弱口令”，而应给出最小化证据，例如“普通域用户可读取部署脚本中的服务账号凭据，该账号可通过 WinRM 登录 APP01，并属于 APP01 本地 Administrators；未发现其具备域管理员权限”。

修复复测至少包括：凭据是否已轮换、脚本和备份中是否仍存在旧值、服务账号是否已移除不必要的本地权限、办公网到管理端口的访问控制是否生效，以及 4624、4688、4104 等关键日志能否关联出同类行为。

总结

内网渗透的价值不在于堆叠利用工具，而在于验证权限边界是否被多个配置缺陷共同突破。以“可达面确认—凭据暴露定位—最小化权限验证—日志复核—修复复测”为主线，可以在不扩大影响面的前提下还原真实攻击路径，也能让修复措施从单纯改密码提升到网络隔离、账号治理和审计闭环。

这条链路里建议单独记录“凭据可用”和“权限边界”两个结论：认证成功，不代表具备本地管理员权限；能列出共享，也不代表能读取文件或写入目录。

验证时可以固定一个授权测试目录，用预置标记文件检查读取权限，再用临时文件检查写入权限，避免拿业务文件当验证材料。例如在已建立的授权测试会话里：

# 确认当前令牌及 Kerberos 票据，不在命令行传入明文密码
whoami /all
klist

# 将路径替换为明确获准的测试目录
$root = '\\server\assessment-share\boundary-check'
Get-Content -LiteralPath "$root\read-marker.txt" -ErrorAction Stop

# 仅在范围允许写入时执行，分别记录创建与删除结果
$probe = Join-Path $root ("probe-" + [guid]::NewGuid().ToString('N') + ".txt")
try {
    Set-Content -LiteralPath $probe -Value 'authorized boundary check' -ErrorAction Stop
    Write-Output "创建成功：$probe"
} finally {
    if (Test-Path -LiteralPath $probe) {
        Remove-Item -LiteralPath $probe -ErrorAction Stop
        Write-Output "删除成功：$probe"
    }
}

注意两个容易误判的地方：whoami /all 展示的是当前进程令牌，不能直接证明远端 SMB 使用了同一身份；共享权限与 NTFS 权限也要共同判断，单看一份 ACL 不足以下结论。最好让防守侧按测试时间、源地址、账号和目标路径关联服务端日志：4624 确认登录身份，5140/5145 辅助核对共享访问；后两项需要提前启用相应审计，且不能仅凭共享访问事件就认定文件读取成功。

最终报告按“暴露位置 → 实际认证身份 → 可访问对象 → 成功/拒绝的操作 → 清理结果”留证即可。发现凭据后，先约定轮换窗口和停止条件，不必为了补齐所谓完整链路继续扩大访问范围。