跳转到帖子

渗透攻防实战:一次授权内网测试中的 SMB 横向风险验证与日志留痕排查

精选回复

发布于

背景

最近在一次授权内网渗透测试中,客户环境是典型 Windows 域网络:办公网段与服务器网段之间存在基础 ACL,但部分运维主机同时能访问域控、文件服务器和业务服务器。测试目标不是“拿下域控”,而是验证一类常见风险:普通办公终端被控后,攻击者能否通过凭据复用、共享目录暴露、远程服务权限边界不清,完成横向移动。

本文只记录授权测试中的验证思路、排查方法和修复建议,重点放在 SMB、Windows 远程管理、日志留痕与权限边界检查。涉及命令均以测试账号和授权资产为前提。

测试场景

  • 域名:corp.local
  • 测试跳板机:10.10.20.15,普通域用户权限
  • 目标服务器段:10.10.30.0/24
  • 重点服务:SMB 445、WinRM 5985、RDP 3389
  • 测试账号:corp\audit.user,仅授权用于漏洞验证

前期信息收集发现,部分业务服务器开放 445,且存在命名类似 deploy、backup、share 的共享目录。这类目录经常是内网横向链路的突破点:不是漏洞本身,而是权限配置长期失控。

问题定位

定位思路分三步:先确认网络连通性,再确认认证边界,最后验证共享目录权限是否过宽。

常见误区是直接上工具批量扫,这在生产环境容易制造大量 4625 登录失败日志,甚至触发账号锁定策略。更稳妥的方式是小范围抽样,先确认策略,再逐步扩大。

# 1. 确认 445/5985/3389 端口开放情况,控制速率,避免对生产造成压力
nmap -Pn -p 445,5985,3389 --open --max-rate 50 10.10.30.0/24 -oA corp_srv_basic

# 2. 使用当前授权账号查看指定主机 SMB 共享,不做口令爆破
net view \\10.10.30.21 /all

# 3. Windows 下查看当前登录身份与 Kerberos 票据状态
whoami /user
whoami /groups
klist

# 4. Linux 测试机上验证 SMB 认证与共享列表
smbclient -L //10.10.30.21 -U 'corp.local/audit.user'

如果 net view 或 smbclient -L 能列出共享,并不代表一定可写。真正关键的是目录 ACL。测试时需要验证“读、写、删除、执行”四类权限,尤其是写入后能否被服务端任务、脚本或运维流程自动执行。

技术分析

本次发现的主要问题不是单点漏洞,而是权限链路叠加:

  • 普通域用户可以访问多台服务器的部署共享目录。
  • 共享目录 NTFS 权限中存在 Domain Users: Modify。
  • 部分服务器开启 WinRM,且本地 Administrators 组中加入了过宽的域组。
  • 共享目录中遗留脚本包含明文连接串和服务账号信息。

在渗透攻防场景里,这类问题比单个 CVE 更常见。因为它不依赖漏洞利用,只依赖“权限边界配置错误”。攻击链大致如下:

  • 获得一个普通域账号。
  • 枚举可访问服务器与共享目录。
  • 发现可写共享或敏感脚本。
  • 提取配置中的服务账号或验证本地管理员组权限。
  • 通过 WinRM/RDP/计划任务等授权通道完成横向。

这里要注意:验证是否可横向,不一定要执行高风险载荷。很多时候通过只读命令、权限查询和事件日志即可证明风险。

操作步骤

1. 枚举共享与 ACL

在 Windows 测试机上可以使用 PowerShell 检查共享访问结果。下面示例只对已授权网段执行,并记录访问成功与失败情况。

$targets = Get-Content .\targets.txt
$shares = @("C$", "ADMIN$", "IPC$", "share", "deploy", "backup")

foreach ($t in $targets) {
    foreach ($s in $shares) {
        $path = "\\$t\$s"
        try {
            $items = Get-ChildItem $path -ErrorAction Stop | Select-Object -First 3
            Write-Host "[+] Accessible: $path" -ForegroundColor Green
            $items | ForEach-Object { Write-Host "    $($_.Name)" }
        } catch {
            Write-Host "[-] Denied/Failed: $path" -ForegroundColor DarkGray
        }
    }
}

如果发现可访问目录,继续查看 ACL。重点看是否存在 Everyone、Authenticated Users、Domain Users 拥有 Modify 或 FullControl。

# 查看共享目录 NTFS 权限
icacls "\\10.10.30.21\deploy"

# 典型风险输出示例
# CORP\Domain Users:(OI)(CI)(M)
# BUILTIN\Administrators:(OI)(CI)(F)
# NT AUTHORITY\SYSTEM:(OI)(CI)(F)

(M) 表示 Modify,通常意味着可以写入、修改和删除文件。对于部署目录、脚本目录、备份目录来说,这个权限非常危险。

2. 验证写权限但避免破坏

验证写权限时不要上传可执行文件,不要覆盖业务文件。建议写入一个带时间戳的空文本文件,然后立即删除,保留截图或命令输出作为证据。

$testFile = "\\10.10.30.21\deploy\pt_write_test_$env:USERNAME.txt"
"authorized penetration test $(Get-Date)" | Out-File $testFile -Encoding utf8
Get-Item $testFile
Remove-Item $testFile -Force

如果写入成功,报告里应明确写明:普通域用户对部署共享具备写权限,可能被用于投递恶意脚本、篡改发布包、植入配置文件或替换 DLL。是否真实执行,需要结合该目录是否被服务、计划任务、CI/CD 流程调用。

3. 检查敏感配置泄露

很多内网横向并不是靠漏洞,而是从脚本里翻出密码。可以在授权目录中检索关键词,但要注意只读取必要文件,不批量下载业务数据。

# 在共享目录中搜索常见敏感关键字
Select-String -Path "\\10.10.30.21\deploy\*.config","\\10.10.30.21\deploy\*.ps1","\\10.10.30.21\deploy\*.bat" `
  -Pattern "password|passwd|pwd|uid|user id|connectionString|token|secret" `
  -CaseSensitive:$false

如果发现连接串或服务账号,应验证其权限边界,而不是直接扩大利用。例如只检查该账号是否属于敏感组、是否能访问不该访问的主机。

# 查询当前账号组信息
whoami /groups

# 查询某个域组成员,需具备相应查询权限
net group "Domain Admins" /domain
net group "Server Operators" /domain

4. 验证 WinRM 权限边界

WinRM 开启本身不是漏洞,问题在于谁可以远程登录。测试时可以只执行低风险命令,例如 hostname、whoami,用于确认是否具备远程执行权限。

# PowerShell 远程命令,仅用于授权验证
$cred = Get-Credential corp\audit.user
Invoke-Command -ComputerName 10.10.30.21 -Credential $cred -ScriptBlock {
    hostname
    whoami
    whoami /groups
}

如果普通测试账号可通过 WinRM 登录服务器,应进一步检查目标服务器本地组:

# 在目标主机上查看本地管理员和远程管理用户组
net localgroup administrators
net localgroup "Remote Management Users"
net localgroup "Remote Desktop Users"

常见问题是将 Domain Users、过大的运维组、历史遗留组加入了本地管理员或远程管理组,导致权限面扩大。

日志留痕与排查方法

渗透测试完成后,应主动协助客户定位日志。这样既能证明测试行为可审计,也能帮助蓝队完善检测规则。

行为关键日志说明
SMB 登录成功Windows Security 4624Logon Type 常见为 3,来源 IP 为测试机
SMB 登录失败Windows Security 4625用于确认是否触发爆破或账号锁定风险
访问共享对象5140、5145需开启对象访问审计,能看到共享名和访问结果
WinRM 远程执行4688、4624、PowerShell 4104结合进程创建与脚本块日志排查
RDP 登录4624、4778、4779关注 Logon Type 10

常用排查命令如下:

# 查询指定时间段 SMB 登录成功记录
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-6)} |
  Where-Object { $_.Properties[8].Value -eq 3 } |
  Select-Object TimeCreated, Id, ProviderName, Message -First 20

# 查询共享访问事件
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5140; StartTime=(Get-Date).AddHours(-6)} |
  Select-Object TimeCreated, Message -First 20

# 查询 PowerShell 脚本块日志
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104; StartTime=(Get-Date).AddHours(-6)} |
  Select-Object TimeCreated, Message -First 20

如果生产环境未开启 5140/5145 或 4104,建议在整改阶段补齐审计策略,否则后续出现真实事件时很难回溯共享访问和远程命令行为。

风险与修复建议

  • 收敛共享权限:共享权限和 NTFS 权限同时检查,避免只改一层。部署目录不应给 Domain Users、Authenticated Users 写权限。
  • 拆分运维账号:普通办公账号、服务器运维账号、域管理账号分离。禁止日常办公账号具备服务器本地管理员权限。
  • 清理本地组:重点检查 Administrators、Remote Desktop Users、Remote Management Users,移除过宽域组。
  • 治理明文凭据:脚本和配置文件中的密码迁移到凭据库或受控配置中心,历史文件和备份文件也要一起清理。
  • 限制横向通道:服务器段仅允许堡垒机或运维网段访问 445、3389、5985,不允许办公网直连。
  • 开启审计:启用对象访问审计、PowerShell Script Block Logging、进程创建日志,并集中到 SIEM 或日志平台。
  • 设置账号保护:对高权限账号启用“账号不可委派”、限制登录主机,使用 LAPS 或 Windows LAPS 管理本地管理员密码。

一个相对稳妥的共享权限基线可以参考:

# 示例:移除 Domain Users 写权限,仅保留发布服务账号和管理员
icacls D:\Deploy /inheritance:r
icacls D:\Deploy /remove "CORP\Domain Users"
icacls D:\Deploy /grant "CORP\deploy_svc:(OI)(CI)(M)"
icacls D:\Deploy /grant "BUILTIN\Administrators:(OI)(CI)(F)"
icacls D:\Deploy /grant "NT AUTHORITY\SYSTEM:(OI)(CI)(F)"

# 查看最终权限
icacls D:\Deploy
整改时不要直接在生产目录批量替换权限,建议先导出现有 ACL,确认业务发布流程依赖,再分批调整并保留回滚方案。

总结

这类内网渗透验证的价值不在于使用了多复杂的工具,而在于把“普通账号能走到哪里、能写什么、能远程到哪台机器、日志是否能看见”讲清楚。SMB 共享、WinRM、RDP、本地组和脚本凭据,是企业内网里最容易形成横向链路的几个点。

做授权渗透测试时,建议把验证控制在最小必要范围:不爆破、不破坏、不投递高风险载荷,通过权限查询、低风险写入测试和日志关联就能证明问题。对防守方来说,收敛权限边界、补齐日志、分离账号,比单纯堆安全设备更有效。

服务器与云环境安全示意图
服务器、云资产与权限边界梳理示意
这个场景里建议把“横向是否成功”和“日志是否可还原路径”分开验证,不然最后很容易只看到一堆 4624/5140,但说不清具体是哪个账号从哪台机器打到哪台机器。 可以重点补两类证据: 1. **SMB 会话与共享访问证据** 目标机上看安全日志时,建议优先筛这些事件: - `4624`:登录成功,重点看 `Logon Type = 3` - `4627`:组成员信息,确认是否带了管理员组权限 - `4672`:分配了特殊权限,常见于管理员登录 - `5140`:访问共享对象 - `5145`:详细共享访问,能看到具体相对路径和权限 - `7045`:服务创建,常用于 psexec 类横向验证 - `4697`:服务安装,部分系统策略开启后可见 - `4688`:进程创建,前提是开了进程审计 PowerShell 可以这样快速拉取目标时间段的痕迹:
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624,4672,5140,5145
    StartTime=(Get-Date).AddHours(-6)
} | Select-Object TimeCreated,Id,@{
    n='IpAddress';e={$_.Properties[18].Value}
},@{
    n='TargetUser';e={$_.Properties[5].Value}
},Message | Format-List
如果你们测试了类似远程服务执行,再补查 System 日志:
Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
    StartTime=(Get-Date).AddHours(-6)
} | Select-Object TimeCreated,ProviderName,Id,Message | Format-List
2. **确认是否能定位源主机** 很多内网排查时只拿到账号,拿不到源 IP。建议在 DC 和被访问主机两边交叉看。 在被访问主机上,`4624` 的 `Source Network Address` 很关键;在 DC 上,则看: - `4768`:Kerberos TGT 请求 - `4769`:服务票据请求,重点看 `Service Name` 是否为 `cifs/目标主机` - `4776`:NTLM 认证,适合排 NTLM 横向 例如查 CIFS 服务票据:
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4769
    StartTime=(Get-Date).AddHours(-6)
} | Where-Object {
    $_.Message -match 'cifs/'
} | Select-Object TimeCreated,Message | Format-List
如果原帖是在验证 SMB 横向风险,我觉得还可以加一个很实用的检查点:**是否存在本地管理员口令复用**。授权范围内可以用管理面验证,不一定要做破坏性动作。比如只测试 `ADMIN$` 是否可访问:
net use \\目标IP\ADMIN$ /user:域\测试账号 密码
dir \\目标IP\ADMIN$
net use \\目标IP\ADMIN$ /delete
对应目标机上应该能看到 `4624 Type 3`、`5140 ADMIN$`,如果有文件枚举则可能出现 `5145`。这样验证链路比较干净,后续报告里也容易复现。 另外建议提前把这几个审计策略打开,否则日志留痕会不完整:
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable
如果要看进程命令行,还需要启用:
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
最后防护建议不要只写“关闭 SMB”。企业里很多业务依赖 SMB,更实际的是: - 禁用 SMBv1 - 本地管理员口令唯一化,优先上 LAPS / Windows LAPS - 限制普通终端访问 `ADMIN$`、`C$` - 开启 Windows 防火墙,仅允许管理网段访问 445 - 域管理员不要登录普通终端 - 对 `7045`、`4624 Type 3 + 4672`、`4769 cifs` 做关联告警 这样报告里既能证明横向风险,也能证明蓝队侧是否具备还原攻击路径的能力。

创建帐户或登录后发表意见

最近浏览 0

  • 没有会员查看此页面。