Kali 下使用 Nmap、NetExec 与 smbclient 做 SMB 权限边界验证

背景

这个场景来自一次授权内网渗透测试：客户给了一个域用户账号，只允许在指定网段内做资产识别、SMB 配置核查、共享目录权限验证，不允许投递载荷、不允许横向执行命令。目标不是“打进去”，而是用 Kali 自带或常用工具把 SMB 暴露面、权限边界和日志留痕说清楚。

测试环境假设如下：

• 测试机：Kali Linux
• 目标网段：192.168.10.0/24
• 已授权账号：CORP\audit.user
• 验证范围：SMB 445、NetBIOS 139、共享目录访问、SMB 签名、匿名/Guest 访问、域口令策略只读查询

注意：下面命令都以“已授权、只读验证”为边界，不包含远程命令执行、凭据喷洒、hash 传递或持久化操作。

问题定位

在内网评估里，SMB 常见问题不是单点漏洞，而是配置和权限边界问题。例如：

• 普通域用户能读取部门共享中的敏感文件。
• 匿名或 Guest 能枚举共享、读取目录。
• SMB 签名未启用，存在中间人攻击风险。
• 大量主机开放 445，但没有资产台账。
• 本地管理员组权限扩散，虽然本次不执行命令，但需要确认风险范围。

排查顺序建议是：先做端口和服务指纹，再做 SMB 配置验证，最后做共享目录权限验证。这样证据链比较清晰，也便于后续修复。

工具准备

Kali 默认带有 nmap 和 smbclient。NetExec 有些版本需要单独安装，建议使用 pipx，避免污染系统 Python 环境。

sudo apt update
sudo apt install -y nmap smbclient python3-pip pipx
pipx ensurepath
pipx install git+

# 验证工具版本
nmap --version
smbclient --version
nxc --version

如果环境不能联网，建议在测试前离线准备好工具包，并记录工具版本。内网项目中工具版本很重要，同一条命令在不同版本下输出字段可能不同，后面写报告时容易对不上。

技术分析

SMB 权限边界验证通常关注四类信息：

这里不建议一上来就用高并发扫描。SMB 服务在老旧服务器、NAS 或文件服务器上可能比较敏感，高并发会造成告警甚至影响业务。初次探测可以控制速率。

操作步骤

1. 发现开放 SMB 的主机

先用 nmap 做轻量端口发现，只看 445 和 139，不做脚本扫描。

nmap -Pn -p 445,139 --open --min-rate 100 -oA smb_discovery_192.168.10 192.168.10.0/24

参数说明：

• -Pn：内网防火墙常丢 ICMP，直接跳过主机存活探测。
• --open：只输出开放端口的主机。
• --min-rate 100：控制基础速率，不建议在生产网段盲目拉高。
• -oA：同时保存 normal、grepable、xml 三种格式，方便后续整理。

可以从 grepable 文件中提取开放 445 的主机：

grep "445/open" smb_discovery_192.168.10.gnmap | awk '{print $2}' > smb_hosts.txt
wc -l smb_hosts.txt

2. 检查 SMB 签名和基础信息

对目标列表执行 SMB 安全配置检查。nmap 的 NSE 脚本适合做配置核查，输出也比较适合进报告。

nmap -Pn -p445 --script smb2-security-mode,smb2-time,smb-protocols \
  -iL smb_hosts.txt -oA smb_security_check

重点看：

• Message signing enabled but not required：启用但不强制，仍有被降级或中间人利用的风险。
• SMBv1：如果仍开启，需要单独列为高风险配置问题。
• 时间偏差：域环境里时间偏差过大可能影响 Kerberos，也能辅助判断主机是否纳入域管控。

3. 使用 NetExec 验证域用户视角

使用授权账号验证普通域用户能看到什么。建议把密码放在交互输入或临时环境变量里，不要写入 shell history。下面示例使用环境变量，执行完应清理。

export SMB_USER='audit.user'
export SMB_PASS='替换为授权测试密码'
export SMB_DOMAIN='CORP'

nxc smb smb_hosts.txt -u "$SMB_USER" -p "$SMB_PASS" -d "$SMB_DOMAIN" --shares --continue-on-success

输出中常见权限字段：

• READ：当前用户可读。
• WRITE：当前用户可写，风险更高。
• NO ACCESS：无法访问。

这里要注意，能列出共享名不等于能访问内容。报告里应区分“可枚举共享”和“可读取共享内容”。

4. 使用 smbclient 做目录级验证

NetExec 适合批量识别，但最终证据建议用 smbclient 对关键共享做手工验证。比如发现 \\192.168.10.25\Finance 对普通域用户可读，可以只列目录，不下载敏感文件。

smbclient //192.168.10.25/Finance -U 'CORP/audit.user'

# 进入 smbclient 后执行：
recurse off
ls
cd 2024
ls

如果必须证明文件内容可读，建议只读取客户明确允许的测试文件，或者让客户提前放置标记文件，例如 security_test_readme.txt。不建议随意下载真实财务、人事、合同文件。

5. 匿名和 Guest 访问验证

匿名访问和 Guest 访问要分开测。很多环境里“空密码匿名”和“Guest 映射”表现不同。

# 匿名枚举共享
smbclient -L //192.168.10.25 -N

# NetExec 批量检查匿名访问
nxc smb smb_hosts.txt -u '' -p '' --shares

# 如果客户允许，可单独验证 Guest
nxc smb smb_hosts.txt -u 'guest' -p '' --shares

如果发现匿名可读共享，建议记录：目标 IP、共享名、权限、可见目录层级、时间点。证据要够，但不要扩大读取范围。

6. 只读查询域口令策略

在域控或支持 RPC 的主机上，可以用 NetExec 查询口令策略。这属于配置核查，不需要爆破。

nxc smb 192.168.10.10 -u "$SMB_USER" -p "$SMB_PASS" -d "$SMB_DOMAIN" --pass-pol

重点关注：

• 最小密码长度是否过低。
• 账户锁定阈值是否未配置。
• 密码最长使用期限是否过长。
• 历史密码记忆是否为 0。

日志留痕与排查方法

SMB 验证会在 Windows 日志中留下痕迹。和蓝队或运维同步时，可以让对方按时间窗口检索以下事件：

排查时建议过滤测试机 IP 和授权账号：

# PowerShell 示例：在目标 Windows 主机上按测试账号和时间段过滤 4624/5140
Get-WinEvent -FilterHashtable @{
  LogName='Security';
  Id=4624,5140;
  StartTime=(Get-Date).AddHours(-4)
} | Where-Object {
  $_.Message -match 'audit.user' -or $_.Message -match '192.168.10.50'
} | Select-Object TimeCreated,Id,ProviderName,Message

如果日志里出现大量 4625，通常是域名前缀、用户名格式或密码输入错误导致，应该立即停止批量验证，先用单台主机确认参数。

风险与修复建议

• 关闭 SMBv1：在服务器和客户端侧都应禁用 SMBv1，优先通过组策略统一下发。
• 强制 SMB 签名：域控和关键服务器建议强制签名，普通服务器至少评估兼容性后逐步开启。
• 收敛共享权限：共享权限和 NTFS 权限都要检查，避免“共享只读但 NTFS 过宽”或反过来的错配。
• 禁止匿名/Guest 访问：文件服务器不应允许匿名读取共享，临时共享要有过期机制。
• 最小权限分组：不要直接把 Domain Users 授权到敏感共享，按业务组授权并定期复核。
• 启用对象访问审计：对关键共享开启 5140/5145 审计，配合 SIEM 监控异常访问。
• 清理测试凭据：测试结束后修改或禁用授权账号，清理 Kali 本地环境变量、命令历史和结果文件。

# Kali 侧测试结束后的基本清理
unset SMB_USER SMB_PASS SMB_DOMAIN
history -d $(history | tail -n 20 | grep 'SMB_PASS' | awk '{print $1}' | head -n 1) 2>/dev/null
chmod 600 smb_* nmap_* 2>/dev/null

总结

在 Kali 下做 SMB 权限边界验证，重点不是工具跑得多，而是边界清楚、证据可复现、日志能对上。推荐流程是：nmap 发现资产，NSE 检查 SMB 配置，NetExec 批量验证授权用户视角，smbclient 对关键共享做手工确认。最终报告里要把“可枚举”“可读取”“可写入”“配置弱项”分开写，修复建议也要落到 SMB 签名、共享权限、匿名访问和审计策略这些具体项上。

这个组合适合做“同一账号在不同工具中的结果交叉验证”，但不要只看 Nmap 枚举出来的共享名就判断权限。SMB 的共享权限和底层 NTFS 权限是两层，最终能否读写通常取两者的交集。

建议按匿名、低权限账号、目标业务账号分别记录结果，先确认协议和签名状态：

nmap -Pn -p445 --script smb-protocols,smb-security-mode <目标IP>

重点看是否允许 SMBv1、是否启用 SMB signing，以及目标是否实际开放 445 而不是仅仅被防火墙过滤。匿名枚举在不同 Windows 版本和域策略下差异很大，匿名失败不代表认证用户没有权限。

使用 NetExec 枚举共享时，建议显式指定域或工作组，避免用户名解析产生误判：

nxc smb <目标IP> -u 'user' -p 'password' -d 'DOMAIN' --shares

输出里的 READ/WRITE 更适合作为快速筛选，最终还要用 smbclient 实际访问确认。例如：

smbclient -L //<目标IP> -U 'DOMAIN/user'
smbclient //<目标IP>/Public -U 'DOMAIN/user' -c 'ls'
smbclient //<目标IP>/Finance -U 'DOMAIN/user' -c 'cd reports; ls'

如果出现“能看到共享但进入失败”，通常是共享级权限允许枚举，而 NTFS ACL 拒绝了目录访问；如果能进入但某个子目录失败，则重点检查继承、显式 Deny，以及账号是否通过嵌套组获得了预期权限。不要把 `--shares` 中的空白、`NO ACCESS` 或连接超时直接等同于权限拒绝，先用同一组凭据在 smbclient 中复现。

对读写边界验证，建议只在明确授权的测试目录中操作，避免直接上传或删除业务文件。可以先确认是否具备写权限，再创建带时间戳的临时文件并立即清理：

printf 'smb-permission-test\n' > /tmp/smb-permission-test.txt

smbclient //<目标IP>/Test -U 'DOMAIN/user' \
  -c 'put /tmp/smb-permission-test.txt permission-test.txt; ls permission-test.txt; del permission-test.txt'

如果上传成功但删除失败，说明权限并不是简单的“可写”，可能存在仅新增、禁止删除或目录权限与文件权限不一致的情况。验证结果最好记录为“可枚举、可读、可新建、可修改、可删除”几个独立维度，而不是只写一个 READ/WRITE 结论。

另外，NetExec 和 smbclient 使用的凭据格式、域上下文可能不同，尤其是本地账号。测试本地账号时可以明确使用工作组或目标主机名作为域，并分别验证：

nxc smb <目标IP> -u 'localuser' -p 'password' -d WORKGROUP --shares
smbclient //<目标IP>/Users -U '<目标主机名>/localuser'

这样能避免把“认证上下文不一致”误判成 SMB ACL 差异。最终报告中建议同时保留命令、目标 IP、账号上下文、共享名、实际操作结果和时间，便于后续和 Windows 端的共享权限及 NTFS ACL 进行对照。