发布于昨天 22:041天前 背景最近在一次授权内网渗透测试中,客户环境是典型 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、本地组和脚本凭据,是企业内网里最容易形成横向链路的几个点。做授权渗透测试时,建议把验证控制在最小必要范围:不爆破、不破坏、不投递高风险载荷,通过权限查询、低风险写入测试和日志关联就能证明问题。对防守方来说,收敛权限边界、补齐日志、分离账号,比单纯堆安全设备更有效。 服务器、云资产与权限边界梳理示意
昨天 23:231天前 这个场景里建议把“横向是否成功”和“日志是否可还原路径”分开验证,不然最后很容易只看到一堆 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` 做关联告警 这样报告里既能证明横向风险,也能证明蓝队侧是否具备还原攻击路径的能力。
创建帐户或登录后发表意见