渗透攻防实战复盘：授权内网测试中的 SMB 横向验证、日志留痕与修复闭环

发布于周六 17:163天前

背景

这篇记录的是一次授权内网渗透测试中的典型链路：从一台普通办公网段主机出发，验证域内 SMB 暴露面、口令风险、权限边界和日志留痕。本文不讨论未授权攻击，也不追求“打穿”，重点放在渗透攻防板块里更常见的几个问题：如何确认风险、如何控制验证范围、如何保留证据、如何给出可落地修复建议。

测试前提：已获得书面授权；测试账号、测试网段、允许的验证方式均在范围内；不进行破坏性操作，不落地后门，不清理日志。

测试场景

内网域环境：Windows Server AD 域。
测试入口：一台普通员工网段主机，已接入内网。
授权范围：10.10.20.0/24、10.10.30.0/24 两个网段。
验证目标：SMB 服务暴露、弱口令/口令复用、SMB 签名配置、普通域账号横向访问边界。
禁止事项：禁止上传木马、禁止持久化、禁止删除或修改业务数据。

问题定位思路

内网横向验证不要一上来就跑全网爆破。比较稳妥的顺序是：

先确认资产和端口：只看授权网段内的 445、139、135 等基础服务。
再确认域环境：域名、域控、DNS、时间同步情况。
使用授权测试账号验证访问边界：判断哪些主机允许普通域账号访问管理共享或普通共享。
最后结合 Windows 日志确认是否产生异常认证、失败登录、远程服务创建等痕迹。

这类测试的核心不是“能不能登录更多机器”，而是确认企业内网是否存在以下问题：

本地管理员口令复用。
域普通账号拥有不该有的本地管理员权限。
SMB 签名未启用，存在中继风险。
共享目录权限过宽，敏感文件可读。
日志审计不足，横向行为难以追溯。

技术分析

SMB 横向验证里比较关键的是权限边界。常见误区是把“能访问 IPC$”当成“已拿到主机权限”。实际上，IPC$ 可连通只能说明认证成功或匿名策略允许部分访问，不能直接代表管理员权限。

建议区分三类结果：

结果类型	含义	风险判断
认证成功但无管理共享权限	账号有效，但不是本地管理员	主要风险是口令暴露面
可访问 ADMIN$ / C$	账号具备本地管理员权限	高风险，可能被用于横向移动
可读业务共享目录	共享 ACL 配置过宽	视数据敏感程度定级

另外，SMB 签名配置也很重要。如果客户端和服务端均不强制签名，在存在 LLMNR/NBNS 投毒、错误代理配置或中间人条件时，可能被利用做认证中继。授权测试中通常只做配置验证，不建议在生产网段直接做中继攻击验证，避免影响业务。

操作步骤

1. 确认域基础信息

在 Windows 测试机上可以先确认当前域、登录用户、域控发现情况：

whoami /user
whoami /groups
nltest /dsgetdc:example.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local
net config workstation

如果是 Linux 测试机，可通过 DNS 和 Kerberos 配置侧面判断：

dig SRV _ldap._tcp.dc._msdcs.example.local
crackmapexec smb 10.10.20.0/24 --dns-server 10.10.20.10

2. 探测授权网段 SMB 暴露

这里建议只扫描授权网段和必要端口，避免扩大影响面：

nmap -Pn -n -p 445,139 --open 10.10.20.0/24 10.10.30.0/24 -oA smb_scan_authorized

如果目标较多，可以先生成存活 SMB 主机列表，后续所有验证只读取这个列表：

awk '/445\/open/ {print $2}' smb_scan_authorized.gnmap > smb_hosts.txt
cat smb_hosts.txt

3. 使用授权账号验证访问边界

下面示例使用的是测试授权账号，不建议使用真实高权限管理员账号做批量验证，容易扩大风险，也会污染审计结果。

# 验证域账号是否能正常认证
crackmapexec smb smb_hosts.txt -d example.local -u audit_test -p 'TestPassword!23'

# 检查是否存在本地管理员权限，重点关注 Pwn3d! 或 admin 标记
crackmapexec smb smb_hosts.txt -d example.local -u audit_test -p 'TestPassword!23' --shares

# 检查 SMB 签名配置
crackmapexec smb smb_hosts.txt --gen-relay-list smb_no_signing.txt
cat smb_no_signing.txt

输出中需要重点记录三类信息：

哪些主机认证成功。
哪些主机可访问 ADMIN$、C$、业务共享目录。
哪些主机 SMB signing 为 disabled 或 not required。

4. Windows 原生命令复核共享权限

工具结果最好抽样用原生命令复核，避免误判。比如在测试机上检查某台主机共享：

net view \\10.10.20.35 /all
net use \\10.10.20.35\IPC$ /user:example\audit_test TestPassword!23
net view \\10.10.20.35

如果需要确认是否有管理共享访问能力，可以只验证目录列举，不做写入：

dir \\10.10.20.35\C$\Users
net use \\10.10.20.35\IPC$ /delete

测试完成后主动断开连接，避免凭据缓存或连接残留影响后续排查。

5. 日志留痕排查

渗透测试报告里如果只写“存在横向风险”，说服力不够。建议同时给出对应日志证据，方便蓝队复核。

在被访问主机和域控上重点关注以下事件：

事件 ID	位置	含义
4624	目标主机安全日志	登录成功，Type 3 表示网络登录
4625	目标主机安全日志	登录失败，可判断是否存在口令喷洒迹象
4672	目标主机安全日志	分配了特殊权限，常见于管理员登录
5140	目标主机安全日志	访问网络共享对象
4776	域控安全日志	NTLM 认证请求
4768/4769	域控安全日志	Kerberos TGT/TGS 请求

可以使用 PowerShell 抽取近 2 小时内来自测试账号的登录记录：

$StartTime = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$StartTime} |
  Where-Object { $_.Properties[5].Value -like '*audit_test*' -or $_.Message -like '*audit_test*' } |
  Select-Object TimeCreated, Id, ProviderName, Message

如果要定位 SMB 共享访问记录，可以查 5140：

$StartTime = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5140; StartTime=$StartTime} |
  Where-Object { $_.Message -like '*audit_test*' } |
  Select-Object TimeCreated, Id, Message

注意：5140 需要启用对象访问审计策略，否则可能没有记录。域环境里建议通过 GPO 开启：

Computer Configuration
 └─ Windows Settings
    └─ Security Settings
       └─ Advanced Audit Policy Configuration
          └─ Object Access
             └─ Audit File Share: Success, Failure

关键发现示例

一次测试中比较典型的结果如下：

10.10.20.35、10.10.20.41、10.10.30.18 对测试账号开放 IPC$。
10.10.20.41 可访问 C$，说明测试账号被加入了该主机本地 Administrators 组。
10.10.30.18 存在 public 共享目录，Authenticated Users 具备读取权限，目录内发现配置备份文件。
共有 17 台主机 SMB signing 为 not required，存在被中继利用的前置条件。
域控上存在对应 4776 记录，目标主机上存在 4624 Type 3 和 5140 记录，日志链路可追溯。

风险判断

这类问题通常不能只按单点漏洞定级，要看组合风险：

如果只是普通账号能认证 IPC$，但无敏感共享、无管理员权限，风险偏低。
如果普通账号可访问业务共享并读取配置、备份、密码表，风险至少中危。
如果普通账号或复用口令具备多台主机本地管理员权限，风险高。
如果同时存在 SMB signing 不强制、NTLM 使用广泛、LLMNR/NBNS 开启，横向中继风险明显升高。

修复建议

1. 收敛本地管理员权限

清理普通域用户在终端和服务器本地 Administrators 组中的权限。
业务运维账号按系统分组授权，避免一个账号管理全部服务器。
定期导出本地管理员组成员，与 CMDB 或堡垒机授权列表比对。

# 在目标主机检查本地管理员组成员
net localgroup administrators

# PowerShell 查看本地管理员组
Get-LocalGroupMember -Group "Administrators"

2. 处理本地管理员口令复用

启用 Windows LAPS 或 Microsoft LAPS，为每台主机生成独立本地管理员密码。
禁止多个终端使用相同本地 Administrator 密码。
限制本地管理员账号远程登录。

# 建议策略路径
Computer Configuration
 └─ Administrative Templates
    └─ LAPS
       ├─ Enable local admin password management
       ├─ Password Settings
       └─ Name of administrator account to manage

3. 强制 SMB 签名

域控和关键服务器建议强制 SMB signing，普通终端至少应评估兼容性后逐步启用。

# 查看 SMB 服务端签名配置
Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature

# 查看 SMB 客户端签名配置
Get-SmbClientConfiguration | Select EnableSecuritySignature, RequireSecuritySignature

# 强制服务端 SMB 签名
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# 强制客户端 SMB 签名
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

4. 关闭不必要的名称解析协议

如果环境中不依赖 LLMNR/NBNS，建议关闭，降低凭据被诱导发起 NTLM 认证的概率。

# GPO 路径：关闭 LLMNR
Computer Configuration
 └─ Administrative Templates
    └─ Network
       └─ DNS Client
          └─ Turn off multicast name resolution: Enabled

NetBIOS over TCP/IP 可结合网卡配置和 DHCP 选项逐步禁用，避免影响老旧系统。

5. 收紧共享目录 ACL

避免 Everyone、Authenticated Users 对敏感共享具备读取权限。
共享权限和 NTFS 权限都要检查，最终权限取两者交集。
配置备份、数据库连接串、运维脚本不要放在公共共享目录。

# 查看共享
Get-SmbShare

# 查看共享权限
Get-SmbShareAccess -Name "public"

# 查看 NTFS 权限
icacls D:\Share\public

6. 完善审计策略

开启登录成功/失败审计。
开启文件共享访问审计，至少覆盖关键服务器。
将 4624、4625、4672、4776、5140 等事件接入 SIEM。
对短时间内多主机 Type 3 登录、同账号多源失败登录设置告警。

auditpol /get /category:*

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable

总结

授权内网渗透测试里，SMB 横向验证很容易被做成“工具一扫、结果一贴”。更可靠的做法是：限定范围、区分认证成功和管理员权限、抽样复核、保留日志证据，并把修复建议落到 GPO、ACL、LAPS、SMB signing 和审计策略上。

从攻防角度看，这条链路的价值不在于证明某个工具能跑通，而在于帮助企业确认权限边界是否清晰、口令是否隔离、日志是否可追溯。能闭环修复的渗透测试，才真正有意义。

周六 17:173天前

这类复盘里建议把“SMB 横向验证”和“横向执行”明确拆开：仅能访问 ADMIN$、C$ 或建立 SMB 会话，不等于已经完成远程执行。报告中最好分别记录凭据来源、认证结果、共享访问、服务创建/计划任务/远程管理等后续动作，避免把单一日志事件直接定性为“主机失陷”。

日志留痕可以按下面这条链路核对：

目标主机：4624/4625，重点看 LogonType=3、源 IP、账户、认证包和登录时间；
共享访问：5140、5145，确认访问了哪个共享和相对路径；
特权使用：4672，判断该网络登录是否获得了高权限令牌；
远程执行：7045（服务创建）、4698（计划任务）、4688（进程创建）；
域环境：域控侧补看 4768、4769、4776，用于区分 Kerberos、NTLM 以及凭据验证位置。

例如在目标机上可以先做一轮时间窗口查询，重点不要只看事件数量，还要把源地址和账户串起来：

$start = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624,4625,4672,5140,5145,4688
    StartTime = $start
} | ForEach-Object {
    [pscustomobject]@{
        Time = $_.TimeCreated
        Id   = $_.Id
        Text = $_.Message
    }
} | Format-List

SMB 配置项也建议在验证前后留基线，尤其是 SMB 签名和 SMBv1，不要只凭“端口 445 可达”下结论：

Get-SmbServerConfiguration |
    Select EnableSMB1Protocol,EnableSMB2Protocol,
           EnableSecuritySignature,RequireSecuritySignature

Get-SmbClientConfiguration |
    Select EnableSecuritySignature,RequireSecuritySignature

Get-SmbSession
Get-SmbOpenFile

修复验证最好做成闭环而不是只贴一张配置截图：

先确认业务是否仍依赖 SMBv1、匿名共享、旧设备或未签名访问；
通过 GPO 或基线统一要求 SMB 签名，分批在服务器、客户端验证兼容性；
收紧管理共享和高权限账户的网络登录范围，普通用户不应具备本地管理员权限；
开启对象访问及进程创建审计，并确保日志转发到集中平台，保留源 IP、目标主机、账户和会话关联字段；
用同一测试路径做复测：未授权账户、受限账户、授权管理员账户分别验证，确认“应成功”和“应失败”的结果都能在日志中对应起来。

另外，关闭 SMBv1 或强制签名后要检查异常告警量和业务错误日志；如果只验证配置状态，没有验证旧客户端、打印服务、备份软件等实际连接，容易出现“安全配置已修复但业务上线后回滚”的情况。

周六 19:343天前

补充一个我在内网授权测试里比较常用的闭环做法：把“验证动作”和“日志证据”用同一个时间戳/工单编号绑定起来，后面复盘会少很多争议。 SMB 横向验证阶段建议尽量避免用会产生远程执行痕迹的工具链，比如不要一上来就 psexec/wmiexec。可以先做只读验证，控制动作边界：

# 仅验证认证与共享枚举，不写入文件
net use \\10.10.10.23\IPC$ /user:DOMAIN\test_user "password"
net view \\10.10.10.23 /all

# 指定共享做目录级验证，避免遍历全盘
dir \\10.10.10.23\C$\Users

# 验证完成后立即断开，减少会话残留
net use \\10.10.10.23\IPC$ /delete
net use \\10.10.10.23\C$ /delete

如果必须验证写权限，我一般会约定一个固定标记文件，并且只写到临时目录，结束后删除，同时在报告中写清楚文件名和哈希：

echo authorized_test_20250101 > \\10.10.10.23\C$\Windows\Temp\auth_smb_test.txt
certutil -hashfile \\10.10.10.23\C$\Windows\Temp\auth_smb_test.txt SHA256
del \\10.10.10.23\C$\Windows\Temp\auth_smb_test.txt

日志侧除了前面提到的安全日志，建议把 SMB Server 的 Operational 日志也拉一下，很多时候比单看 5140/5145 更直观：

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-SMBServer/Operational'
  StartTime=(Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,ProviderName,Message

另外有个容易漏的点：如果是本地管理员凭据访问远程 ADMIN$/C$，需要确认目标机是否受 UAC 远程限制影响。很多“凭据有效但无法管理”的情况，不一定是权限不足，而是 LocalAccountTokenFilterPolicy 或域/本地账户差异导致。可以在目标侧核对：

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

修复闭环里建议不要只写“禁用 SMBv1、改密码”。更有价值的是按风险分层处理：

本地管理员口令：启用 LAPS / Windows LAPS，确保每台机器本地管理员密码不同。
管理入口：限制 ADMIN$、C$ 访问来源，只允许运维跳板机或管理网段。
账号策略：高权限账号禁止登录普通终端，拆分日常账号和管理账号。
协议侧：关闭 SMBv1，要求 SMB 签名，必要时开启 NTLM 审计并逐步收敛 NTLM。
检测侧：对“短时间内同一账户访问多台主机的 ADMIN$/C$”做告警，比单点 4624 更有实战价值。

可以加一条简单的 Windows 防火墙收敛示例，只允许管理网段访问 SMB：

New-NetFirewallRule `
  -DisplayName "Allow SMB from Admin Subnet" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 445 `
  -RemoteAddress 10.10.100.0/24 `
  -Action Allow

New-NetFirewallRule `
  -DisplayName "Block SMB from Others" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 445 `
  -Action Block

报告里最后最好给一个结论矩阵，例如“认证成功 / 共享可读 / 可写 / 是否远程执行 / 是否拿到高权限令牌 / 对应日志事件”。这样安全、运维、业务三方看同一份复盘时，能明确哪些是验证行为，哪些才是真正的横向执行风险。

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

注册帐户

立刻登录

https://www.hackhat.org/Hacker-topic/26886.html/

粉丝

转到主题列表

没有会员查看此页面。

登录