渗透攻防实战：内网 SMB/LDAP 权限边界验证、日志留痕与加固闭环

背景

在一次授权内网渗透测试中，目标是验证办公网到服务器区的横向移动风险，不做密码爆破、不做持久化、不落地木马，重点检查 Windows 域环境里的权限边界、认证协议配置和日志留痕能力。

这类测试里比较常见的问题不是单点漏洞，而是组合风险：SMB 签名未强制、LDAP 签名未开启、NTLM 使用范围过大、LLMNR/NBNS/WPAD 仍在网内工作，再叠加过度授权的普通域账号，就可能形成较清晰的内网攻防链路。

本文内容限定在授权渗透测试和防护验证场景，重点放在验证方法、证据采集、日志排查和修复建议，不展开攻击性利用细节。

测试场景

• 域环境：Windows Server 域控，客户端以 Windows 10/11 为主。
• 测试范围：办公网段、部分服务器网段、域控及文件服务器。
• 账号权限：提供一个普通域账号，用于验证最小权限边界。
• 测试目标：确认是否存在 NTLM 认证滥用面、SMB/LDAP 安全配置缺失、横向访问权限过宽、日志是否可追踪。

问题定位思路

我一般会按三条线并行排查：

• 协议配置：SMB 签名是否强制、LDAP 是否要求签名和通道绑定、NTLM 是否被审计或限制。
• 权限边界：普通域账号是否能访问非必要共享、远程管理端口、服务器本地管理员组。
• 日志留痕：域控、文件服务器、安全设备是否能记录 NTLM、SMB 登录、LDAP 简单绑定等关键行为。

技术分析

在内网渗透里，SMB 和 LDAP 是非常关键的两个面。SMB 签名未强制时，认证过程更容易被中间人场景影响；LDAP 未要求签名或通道绑定时，目录服务认证边界会变弱。即使不执行实际利用，仅从配置层面也可以判断风险级别。

需要注意的是，很多环境只关注域控补丁，而忽略了成员服务器、文件服务器、老旧业务服务器。实际横向链路里，最容易成为跳板的往往不是域控，而是长期运行、权限复杂、日志薄弱的中间服务器。

操作步骤

1. 确认 SMB 签名状态

先从网络层批量确认 SMB 安全模式，重点看 message_signing 是否为 required。若是 disabled 或 enabled but not required，需要进一步确认业务影响和风险等级。

nmap -Pn -p445 --script smb2-security-mode 10.10.20.0/24 -oA smb_signing_check

# 单机 PowerShell 查看 SMB 服务端配置
Get-SmbServerConfiguration | Select EnableSecuritySignature,RequireSecuritySignature,RejectUnencryptedAccess

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

常见结果判断：

• RequireSecuritySignature: False：SMB 服务端未强制签名，建议列为高优先级整改。
• EnableSecuritySignature: True 但 RequireSecuritySignature: False：支持签名但不强制，风险仍然存在。
• 文件服务器、域控、跳板机应优先强制签名。

2. 检查 LDAP 签名与通道绑定

LDAP 相关配置主要关注两项：LDAP signing 和 LDAP channel binding。测试时不建议直接做破坏性验证，优先通过注册表、组策略和事件日志确认。

# 在域控上查看 LDAP 签名策略
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity

# 查看 LDAP Channel Binding 配置
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LdapEnforceChannelBinding

# 常见取值参考
# LDAPServerIntegrity = 2 表示要求 LDAP 签名
# LdapEnforceChannelBinding = 2 表示强制 LDAP 通道绑定

如果环境里存在大量老系统或旧中间件，直接强制 LDAP 签名可能会影响业务。建议先打开审计，收集一段时间的未签名绑定来源，再分批整改。

3. 关注关键日志事件

授权测试时，日志证据比“能不能打通”更重要。下面这些事件能帮助蓝队确认是否具备追踪能力。

日志位置	事件 ID	用途
域控 Security	4624	成功登录，关注 LogonType 3、AuthenticationPackage 为 NTLM
域控 Security	4625	失败登录，可用于发现异常横向尝试
域控 Security	4776	NTLM 认证验证，定位来源主机和账号
Directory Service	2889	LDAP 未签名简单绑定来源
NTLM Operational	8004	NTLM 审计事件，辅助定位使用 NTLM 的服务
Sysmon	3	网络连接，辅助还原主机到主机的访问链路

域控上可以用 PowerShell 快速拉取近期 NTLM 认证事件：

# 查询近 24 小时 NTLM 验证事件
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4776; StartTime=$start} |
  Select-Object TimeCreated,
    @{n='Account';e={$_.Properties[0].Value}},
    @{n='Workstation';e={$_.Properties[1].Value}},
    @{n='Status';e={$_.Properties[3].Value}} |
  Sort-Object TimeCreated -Descending |
  Format-Table -AutoSize

4. 验证普通域账号权限边界

这里建议遵循最小化原则，只验证访问边界，不做破坏性操作。重点检查普通域账号是否能访问敏感共享、是否能远程登录服务器、是否被错误加入本地管理员组。

# 查看当前账号可见的域共享资源
net view /domain
net view \\fileserver01

# 测试是否存在不应访问的管理共享，正常普通账号应被拒绝
net use \\server01\c$ /user:DOMAIN\test.user

# 查询目标机器本地管理员组成员，需要具备相应读取权限
net localgroup administrators /domain

如果普通账号能访问 C$、ADMIN$ 或服务器运维目录，需要立即确认是否为历史遗留授权、GPO 配置错误或共享权限继承导致。

5. 排查 LLMNR/NBNS/WPAD 暴露面

很多内网里仍然开着 LLMNR、NBNS 和 WPAD。即使不做凭据捕获，也可以通过网络流量确认是否存在广播解析和代理自动发现。

# 抓包过滤参考
udp.port == 5355 || udp.port == 137 || http.request.uri contains 'wpad'

# Windows 关闭 LLMNR 的组策略路径
计算机配置 -> 管理模板 -> 网络 -> DNS 客户端 -> 关闭多播名称解析 -> 已启用

如果抓包中频繁看到 WPAD、LLMNR 查询，说明客户端在名称解析失败时会向局域网广播请求，容易形成认证泄露和中间人风险。

风险判断

• 高风险：域控或文件服务器 SMB 签名未强制，LDAP 未签名绑定大量存在，普通域账号可访问管理共享。
• 中风险：成员服务器 SMB 签名未强制，NTLM 使用范围广但有日志，LLMNR/NBNS/WPAD 未关闭。
• 低风险：仅少量老旧终端存在弱配置，且网络隔离、日志审计和访问控制较完整。

修复建议

• 通过 GPO 强制关键服务器启用 SMB 签名：Microsoft network server: Digitally sign communications (always) 设置为 Enabled。
• 客户端侧逐步启用 SMB 签名要求，先覆盖服务器区和管理终端，再推广到办公终端。
• 域控启用 LDAP 签名和通道绑定，整改前先打开审计，确认旧业务系统兼容性。
• 关闭 LLMNR，禁用不必要的 NetBIOS over TCP/IP，清理 WPAD 自动发现依赖。
• 限制 NTLM 使用范围，优先推动 Kerberos；对确需 NTLM 的系统做白名单和日志审计。
• 清理普通域账号对服务器共享、远程管理端口、本地管理员组的过度授权。
• 在域控、文件服务器、跳板机启用集中日志采集，至少覆盖 4624、4625、4776、2889、8004 等事件。

整改验证命令

# 验证 SMB 服务端是否强制签名
Get-SmbServerConfiguration | Select RequireSecuritySignature

# 验证 SMB 客户端是否强制签名
Get-SmbClientConfiguration | Select RequireSecuritySignature

# 验证 LDAP 相关注册表配置
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity
reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v LdapEnforceChannelBinding

# 复查近 24 小时 LDAP 未签名绑定事件
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2889; StartTime=(Get-Date).AddHours(-24)}

总结

内网渗透攻防里，真正决定风险高低的往往不是某个单点漏洞，而是认证协议、权限边界和日志能力的组合。授权测试时建议把 SMB、LDAP、NTLM、LLMNR/NBNS/WPAD 作为一组链路来验证，同时保留可复现证据和日志截图，方便蓝队整改闭环。

我的经验是，先审计、再灰度、最后强制，是这类配置整改最稳的方式。尤其是 LDAP 签名和 NTLM 限制，直接一刀切容易影响老系统，先找清楚是谁在用、为什么用，再推动替换，效果会好很多。

做 SMB/LDAP 权限边界验证时，建议把“能否访问”拆成三块记录：认证来源、授权结果、对象级 ACL，不然后面复盘很容易只看到登录成功，看不到越权路径。 一个比较实用的验证流程： 1. SMB 侧先拉共享与权限基线

# 查看共享
net view \\target /all

# 指定账号测试访问
net use \\target\share /user:DOMAIN\testuser *

# 查看共享权限与 NTFS ACL
icacls \\target\share

注意共享权限和 NTFS 权限要取交集，很多误判来自共享层是 Read，但目录 ACL 给了 Modify。重点关注： - Everyone / Authenticated Users 是否有写权限 - 普通域用户是否能写入脚本目录、软件分发目录、登录脚本目录 - 是否存在可写但可执行路径，容易形成横向移动落点 2. LDAP 侧建议重点看对象权限，不只看组成员 可以用 PowerView 做边界验证：

Get-DomainUser testuser -Properties memberof
Get-DomainObjectAcl -Identity "CN=目标对象,OU=xxx,DC=domain,DC=local" -ResolveGUIDs
Find-InterestingDomainAcl -ResolveGUIDs

重点排查这些权限： - GenericAll - GenericWrite - WriteDacl - WriteOwner - ForceChangePassword - AddMember - WriteSPN 这些权限即使没有直接进高权限组，也可能形成提权链。验证时建议用低权限测试账号，不要拿管理员账号扫一遍就下结论。 3. 日志留痕要提前开，不然攻防演练结束后很难闭环 Windows 侧可以关注： - 4624 / 4625：登录成功与失败 - 4672：特殊权限登录 - 5140：访问共享对象 - 5145：详细文件共享访问 - 4662：目录服务对象访问 - 4732 / 4728：加入本地组或域组 - 4738：账号属性变更 - 5136：目录对象修改 SMB 访问审计可以开启对象访问审计和共享审计：

auditpol /set /subcategory:"File Share" /success:enable /failure:enable
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
auditpol /set /subcategory:"File System" /success:enable /failure:enable

LDAP 对象修改建议配合高级审核策略：

auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable

如果是域控，记得同步检查 GPO 是否覆盖了本地 auditpol 配置。 4. 加固闭环建议不要只做“删权限” 实际环境里更稳的是： - 对共享目录做分层：只读、可写、可执行分开 - 普通用户可写目录禁止执行文件 - 清理历史遗留的 Domain Users 写权限 - 对高价值 OU 开启 ACL 变更监控 - 对 WriteDacl / WriteOwner / GenericAll 做定期巡检 - 管理员账号禁止访问普通办公共享，避免凭据暴露 - 域管账号只允许在管理工作站登录 可写目录禁止执行可以用 SRP 或 AppLocker，简单一点可以先从高风险共享开始做：

# 示例：检查某共享下可写目录
icacls D:\Share /T | findstr /i "Everyone Authenticated Users Domain Users"

# 示例：移除 Domain Users 写权限，需先确认业务影响
icacls D:\Share /remove:g "DOMAIN\Domain Users"

最后建议每次验证都输出一张矩阵：账号、目标资源、预期权限、实际权限、日志事件、修复动作。这样 SMB/LDAP 的权限边界验证才不会停留在“发现问题”，而是能真正形成可审计的加固闭环。