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

发布于10月10日10月10日

背景

这篇记录来自一次授权内网渗透测试中的典型场景：测试范围为办公网段和部分 Windows 服务器，目标是验证弱口令、凭据复用、SMB 横向移动风险以及蓝队日志可见性。这里不讨论未授权攻击，也不写通用科普，重点放在渗透攻防板块里更常见的几个环节：漏洞验证、权限边界确认、横向链路分析、日志留痕和修复建议。

环境简化如下：

测试入口：已获得授权的内网接入点，普通域用户权限。
域环境：Windows Server AD，客户端以 Windows 10 / Windows Server 2016 为主。
验证重点：SMB 445、RDP 3389、WinRM 5985、域用户口令复用、本地管理员组配置。
约束条件：不做破坏性操作，不落地木马，不执行持久化，不导出大批量敏感数据。

建议在渗透测试方案里提前写清楚允许验证的协议、允许尝试的账号范围、是否允许密码喷洒、是否允许远程执行命令。很多争议都发生在“授权边界没写细”。

问题定位

内网初始信息收集阶段，发现多个主机开放 445 和 3389。通过域内普通权限查询，可以先确认主机、域控、登录关系和共享情况。这里的关键不是一上来“打穿”，而是把链路拆清楚：

哪些机器开放 SMB？
哪些机器允许当前域用户访问共享？
是否存在域用户被加入本地 Administrators？
是否存在本地管理员口令复用？
横向验证是否会在目标主机产生明显日志？

在 Windows 域环境中，常见风险点包括：

普通域账号对多个服务器存在本地管理员权限。
运维账号长期登录多台服务器，导致凭据暴露面扩大。
SMB 签名未强制，NTLM 认证暴露较多。
事件日志开启不完整，无法还原远程登录和远程服务创建行为。

技术分析

授权渗透中验证 SMB 横向风险，核心是“认证成功”和“权限可用”要分开看。一个账号能访问 IPC$，不代表具备远程执行能力；能枚举共享，也不代表能写入 ADMIN$ 或 C$。实际判断时通常关注以下几个点：

IPC$ 连接是否成功：说明凭据可用于远程 SMB 认证。
ADMIN$ / C$ 是否可写：通常意味着本地管理员权限。
是否能远程创建服务：对应服务控制管理器访问权限。
日志中是否出现 4624、4672、7045、5140、5145 等事件。

常见事件对应关系如下：

事件 ID	位置	含义	排查价值
4624	目标主机 Security	登录成功	关注 LogonType 3、10，来源 IP、账号
4625	目标主机 Security	登录失败	判断是否存在口令喷洒或爆破
4672	目标主机 Security	特殊权限登录	判断是否具备管理员级权限
5140	目标主机 Security	访问网络共享	定位访问了哪个共享，如 IPC$、ADMIN$
5145	目标主机 Security	详细共享访问	判断访问路径、权限请求
7045	目标主机 System	服务被安装	识别远程执行链路，如 PsExec 类行为

操作步骤

以下步骤适合授权测试中的低扰动验证。实际执行前应确认测试窗口、账号范围和日志保留策略。

1. 发现开放 SMB 的主机

优先使用低速率扫描，避免对办公网造成影响。可以按网段逐步扫，不建议全网段高并发。

nmap -sS -Pn -p 445,3389,5985 --open --min-rate 200 10.10.20.0/24 -oA smb_rdp_winrm_scan

2. 使用当前授权账号验证 SMB 认证

这里仅验证认证和共享枚举，不执行命令、不写文件。

crackmapexec smb 10.10.20.0/24 -d CORP -u test.user -p '授权测试密码' --shares

结果中如果出现类似 ADMIN$、C$ 可访问，需要重点记录主机名、IP、账号、时间点。若仅 IPC$ 可访问，说明账号可通过 SMB 认证，但未必具备横向执行条件。

3. 核对本地管理员权限

在不执行远程命令的情况下，可以先通过共享权限和登录事件判断。如果客户允许进一步验证，可使用受控命令确认当前账号是否在远程主机管理员组，但要避免批量执行。

crackmapexec smb 10.10.20.15 -d CORP -u test.user -p '授权测试密码' --local-auth --shares

注意：域账号验证时不要误加 --local-auth。这个参数用于本地账号认证，误用会导致结论偏差。

4. 控制远程执行验证范围

如果项目明确允许验证远程执行能力，建议选择一台测试主机，执行无破坏命令，例如查询主机名或当前用户，避免上传二进制文件。

crackmapexec smb 10.10.20.15 -d CORP -u test.user -p '授权测试密码' -x "whoami && hostname"

这类操作可能触发服务创建或远程进程执行相关日志，测试报告里必须写明执行时间、目标主机和命令内容，方便蓝队对账。

日志排查方法

渗透侧验证完之后，蓝队需要从目标主机和域控两侧还原链路。下面是一些常用查询命令。

目标主机查看 SMB 登录与管理员权限事件：

wevtutil qe Security /q:"*[System[(EventID=4624 or EventID=4672 or EventID=5140 or EventID=5145)]]" /f:text /c:30

查看是否存在远程服务创建：

wevtutil qe System /q:"*[System[(EventID=7045)]]" /f:text /c:20

PowerShell 方式筛选指定时间段：

$Start = Get-Date "2025-01-10 14:00:00"
$End   = Get-Date "2025-01-10 15:00:00"
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4672,5140,5145; StartTime=$Start; EndTime=$End} |
  Select-Object TimeCreated, Id, ProviderName, Message

重点看 4624 中的字段：

Logon Type：3 通常对应网络登录，10 通常对应 RDP。
Account Name：用于确认被使用的账号。
Source Network Address：定位发起端 IP。
Authentication Package：常见为 NTLM 或 Kerberos。

如果出现 4672，说明该登录会话被授予了特殊权限。结合 5140/5145 看到 ADMIN$、C$、IPC$ 访问，可以较完整地证明 SMB 横向链路。

关键配置检查

1. 检查 SMB 签名配置

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature
reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /v RequireSecuritySignature

如果未强制 SMB 签名，在某些网络条件下会增加中继攻击风险。域环境中建议通过组策略统一配置。

2. 检查本地管理员组成员

net localgroup administrators

如果发现普通域用户、部门通用账号、长期共用运维账号在本地管理员组中，应作为高风险项处理。

3. 检查远程管理暴露面

netstat -ano | findstr ":445 :3389 :5985"
winrm enumerate winrm/config/listener

WinRM 如果对办公网大范围开放，需要确认是否确有运维需求，并结合防火墙限制来源。

风险与修复建议

这类问题的修复不能只改一个密码，否则过段时间还会复现。建议按以下顺序处理：

清理本地管理员权限：禁止普通域用户进入服务器本地 Administrators，运维账号按角色最小授权。
治理本地管理员口令复用：使用 Windows LAPS 或同类方案，为每台主机设置唯一随机本地管理员密码。
限制 SMB 横向访问：服务器之间按业务关系放通 445，不要全网互通；办公终端到服务器的 SMB 访问应白名单化。
强制 SMB 签名：通过组策略开启 Microsoft network server/client: Digitally sign communications。
减少 NTLM 暴露：逐步审计并限制 NTLM，优先推动 Kerberos，避免一刀切导致业务中断。
开启高级审核策略：至少覆盖 Logon、Account Logon、Object Access、Policy Change、Privilege Use。
集中化日志：将 Security、System、PowerShell、Sysmon 日志接入 SIEM 或日志平台，保留不少于 180 天。

推荐的审核策略方向：

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable /failure:disable
auditpol /set /subcategory:"Special Logon" /success:enable /failure:disable
auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable

如果部署 Sysmon，可以重点关注远程服务创建、可疑进程链、命令行参数。比如 PsExec 类行为常见现象是服务创建、ADMIN$ 写入、远程进程启动，虽然不同工具表现不同，但日志链路通常能串起来。

报告中建议保留的证据

扫描时间、源 IP、目标 IP、端口开放结果。
使用的授权账号，不记录明文密码。
共享枚举结果，特别是 ADMIN$、C$、IPC$。
是否具备本地管理员权限，以及验证方式。
目标主机日志截图或导出文本，包括 4624、4672、5140、5145、7045。
修复前后的复测结果。

总结

内网渗透里，SMB 横向验证很容易被写成“扫到 445，然后远程执行成功”。但真正有价值的报告应该把权限边界、认证路径、日志证据和修复闭环说清楚。渗透侧要控制动作强度，避免无意义扩大战果；防守侧要能从日志还原行为，知道哪个账号、从哪里、在什么时间访问了哪台机器。

这类问题最终拼的不是单个漏洞，而是账号权限、网络边界和日志审计三件事。把本地管理员权限收紧、SMB 访问面缩小、关键事件留全，大多数常见内网横向链路都会明显变难。

10月10日10月10日

这个主题里，SMB 横向验证建议把“能连通”和“能完成横向动作”分开记录，否则最后很难判断是网络暴露、认证配置问题，还是高权限账号本身被滥用。

验证阶段可以先做无破坏检查：

# 仅验证网络层是否可达
Test-NetConnection -ComputerName 10.10.20.15 -Port 445

# 检查本机 SMB 客户端/服务端关键配置
Get-SmbClientConfiguration | Select EnableSecuritySignature
Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSecuritySignature,RequireSecuritySignature

# 查看当前 SMB 会话和共享连接
Get-SmbSession
Get-SmbConnection

如果需要验证共享权限，建议使用专门的低权限测试账号，只访问预先批准的测试共享，不要直接用域管或管理员账号。记录至少包括源 IP、目标 IP、账号、SMB 协议版本、是否签名、访问的共享名以及实际权限结果。这样后续修复后可以做同样的对照测试。

日志方面，不能只看 4624。比较有价值的关联字段是 Logon ID、源地址、账号和时间窗口：

4624：目标主机上的登录成功，重点看 Logon Type 3 和 Authentication Package；
5140：访问网络共享；
5145：共享对象级访问，适合确认具体路径和权限；
4625：失败认证，适合发现密码喷洒或错误凭据尝试；
7045、4697：如果验证流程涉及服务创建，需要单独确认是否产生了服务安装痕迹；
启用 Sysmon 时，可用网络连接事件辅助确认目标端口 445 的访问来源，但不要把 Sysmon 事件当作唯一证据。

例如在目标机上可以先导出指定时间范围的认证和共享访问日志，避免直接清理或覆盖原始证据：

$start = (Get-Date).AddHours(-2)
$ids = 4624,4625,5140,5145,7045,4697

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = $ids
    StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message |
    Export-Csv .\smb-validation-events.csv -NoTypeInformation -Encoding UTF8

修复闭环建议至少覆盖四层：关闭 SMBv1；按业务范围启用 SMB 签名；限制 445 端口只对必要网段开放；清理不必要的本地管理员权限并使用 LAPS 或等效方案轮换本地管理员密码。Windows 侧示例：

# 确认 SMBv1 状态，变更前先核对业务兼容性
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# 关闭 SMBv1（需按变更流程执行）
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# 要求 SMB 服务端签名
Set-SmbServerConfiguration -RequireSecuritySignature $true -Confirm:$false

# 客户端侧也要求签名
Set-SmbClientConfiguration -RequireSecuritySignature $true -Confirm:$false

最后不要只以“端口关闭”作为验收标准。修复后应重新执行同一组连通性、签名状态、共享权限和日志检索测试，并确认：

非授权网段无法访问 445；
授权路径上的 SMB 会话显示签名要求已生效；
普通测试账号不能访问管理员共享或执行超出授权范围的操作；
SIEM 能关联出源主机、账号、目标主机和共享访问事件；
失败验证不会因为日志策略、审核子类别或日志容量不足而丢失。

另外，测试报告中最好明确区分“观察到的事件”和“推断出的攻击路径”，并保留原始 EVTX、配置快照及时间同步信息。这样修复后的复测结果才具备审计和复盘价值。

10月10日10月10日

补充一个容易被忽略的点：SMB 横向验证结束后，最好把“留痕核对”和“修复验证”也做成固定检查项，不然报告里只有能否访问，闭环会比较弱。 Windows 侧可以重点核对这几类事件： - 4624：登录成功，关注 LogonType=3，确认来源地址、账号、认证包 - 4625：登录失败，排查是否存在爆破或错误凭据重试 - 4672：特权登录，判断是否用了高权限账号 - 5140：访问共享对象 - 5145：详细共享访问，能看到共享名、相对路径、访问掩码 - 7045：服务创建，如果做过 PsExec 类验证一定要查 - 4697：服务安装，部分系统会有 - Sysmon Event ID 3：网络连接 - Sysmon Event ID 1：进程创建，辅助确认横向工具执行链路可以直接在目标机上按时间窗口导出，避免全量翻日志：

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

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4624,4625,4672,5140,5145,4697
    StartTime=$start
} | Select-Object TimeCreated,Id,ProviderName,
    @{n='Message';e={$_.Message}} |
    Export-Csv .\smb_audit_security.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
    StartTime=$start
} | Select-Object TimeCreated,Id,ProviderName,Message |
    Export-Csv .\smb_audit_system.csv -NoTypeInformation -Encoding UTF8

如果环境开了 Sysmon，也建议按目标端和源端各查一次：

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'
    Id=1,3
    StartTime=(Get-Date).AddHours(-2)
} | Select-Object TimeCreated,Id,Message |
    Export-Csv .\smb_audit_sysmon.csv -NoTypeInformation -Encoding UTF8

另外，验证 SMB 签名时别只看本机配置，最好确认实际会话状态。PowerShell 里可以看现有连接：

Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Signed,Encrypted,UserName

如果发现 SMB 签名未启用，修复建议可以分两层写：客户端侧：

Set-SmbClientConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force

服务端侧：

Set-SmbServerConfiguration -EnableSecuritySignature $true -RequireSecuritySignature $true -Force
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

域环境里建议最终通过 GPO 下发，而不是单机改。路径一般是：

Computer Configuration
 └─ Windows Settings
    └─ Security Settings
       └─ Local Policies
          └─ Security Options

Microsoft network client: Digitally sign communications (always)
Microsoft network client: Digitally sign communications (if server agrees)
Microsoft network server: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (if client agrees)

还有一点建议写进闭环：共享权限和 NTFS 权限要分开验证。很多内网问题不是共享开得大，而是共享权限 Everyone/Authenticated Users 放行后，NTFS 又给了过宽权限。可以用下面命令快速留证：

Get-SmbShareAccess -Name "ShareName"

Get-Acl "D:\SharePath" | Format-List

最后报告里可以把一次横向验证拆成四列：网络可达、认证成功、共享访问、动作执行。比如 445 通但认证失败，和认证成功但无写权限，修复方向完全不同；前者偏边界暴露和访问控制，后者偏账号权限和共享/NTFS 配置。这样安全侧和运维侧对整改责任也更容易对齐。

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

注册帐户

立刻登录

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

粉丝

转到主题列表

没有会员查看此页面。

登录