Kali 渗透工具实战：授权内网资产探测、服务验证与日志留痕

背景

在一次已取得书面授权的内网渗透测试中，目标通常不是“扫描得越多越好”，而是在明确网段、时间窗口和禁止事项后，用 Kali 自带工具完成资产发现、服务识别、弱配置验证和证据留存。本文以测试网段 10.20.30.0/24 为例，介绍 Nmap、curl、OpenSSL 与 smbclient 的组合用法，不涉及绕过认证、持久化或未授权利用。

执行前应确认授权范围、允许的源地址、扫描速率、可测试端口以及是否允许账号验证。示例中的地址均为保留测试地址，不能直接套用到非授权网络。

工具安装与完整性检查

Kali 建议优先使用官方 APT 仓库，不要从来源不明的脚本或二进制镜像安装渗透工具。先检查仓库配置和系统时间，再更新软件索引。

grep -vE '^\s*(#|$)' /etc/apt/sources.list
sudo apt update
sudo apt install --yes nmap curl openssl smbclient jq

nmap --version
curl --version
openssl version
smbclient --version

dpkg-query -W -f='${Package}\t${Version}\n' nmap curl openssl smbclient jq
apt-cache policy nmap smbclient

如果项目要求记录工具供应链信息，可将包版本、仓库来源和命令哈希一并写入证据目录。APT 出现签名错误时不应使用允许不安全仓库的参数强行跳过，而应检查系统时间、密钥包和镜像配置。

问题定位：先确认网络路径

扫描结果为空不一定代表目标离线。常见原因包括 VPN 路由未下发、出口接口选择错误、主机禁用 ICMP、测试源地址不在访问控制列表中。应先检查本机地址与路由。

ip -brief address
ip route get 10.20.30.10
ip neigh show
sudo tcpdump -ni any 'host 10.20.30.10 and (icmp or tcp port 443)'

ip route get 可以确认实际出口接口和源地址；抓包则用于区分“请求未发出”“请求发出但无响应”以及“被中间设备复位”。不要仅凭 Nmap 的 filtered 状态判断目标存在漏洞。

操作步骤一：低影响资产发现

先做存活探测，并限制速率。若授权方说明目标禁止响应 ICMP，可直接使用 TCP SYN 探测常见管理端口。所有原始结果保存在独立目录，避免后续整理时丢失证据。

export CASE_ID='PT-2025-017'
export TARGET_NET='10.20.30.0/24'
mkdir -p evidence/${CASE_ID}/{raw,notes}

sudo nmap -sn -PE -PS22,80,443,445 \
  --max-rate 100 --max-retries 2 \
  -oA evidence/${CASE_ID}/raw/01-discovery ${TARGET_NET}

awk '/Status: Up/{print $2}' \
  evidence/${CASE_ID}/raw/01-discovery.gnmap \
  > evidence/${CASE_ID}/raw/live-hosts.txt

-oA 会同时生成普通文本、XML 和 grepable 文件。XML 适合后续导入平台，普通文本便于人工复核。这里没有使用激进时序模板，目的是降低对老旧设备和告警系统的影响。

操作步骤二：端口与版本识别

发现存活地址后，再针对授权端口做服务识别。不要一开始就对整个网段执行全端口、高并发或漏洞脚本扫描。

sudo nmap -sS -sV --version-light \
  -p 22,80,443,445,3389 \
  --open --reason --max-rate 80 --max-retries 2 \
  -iL evidence/${CASE_ID}/raw/live-hosts.txt \
  -oA evidence/${CASE_ID}/raw/02-services

版本横幅只能作为线索。例如反向代理可能隐藏真实后端，管理员也可能修改 Server 字段。漏洞判断必须结合组件实际版本、补丁状态和最小化验证结果。

操作步骤三：验证 HTTPS 配置

对于开放的 443 端口，可用 curl 检查跳转、响应头和证书，再用 OpenSSL 验证协议协商。若站点依赖虚拟主机，应使用授权方提供的域名，避免只访问 IP 得到默认站点。

TARGET_HOST='app.intra.example'
TARGET_IP='10.20.30.10'

curl --resolve "${TARGET_HOST}:443:${TARGET_IP}" \
  --connect-timeout 5 --max-time 10 \
  -sS -D evidence/${CASE_ID}/raw/https-headers.txt \
  -o /dev/null "

openssl s_client -connect "${TARGET_IP}:443" \
  -servername "${TARGET_HOST}" -tls1_2 \
  < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

重点核对证书有效期、SAN 是否匹配、HTTP 是否强制跳转 HTTPS，以及 HSTS、Content-Security-Policy、X-Content-Type-Options 等响应头。缺少某个安全头通常属于配置风险，不应直接描述为可远程接管。

操作步骤四：验证 SMB 暴露边界

若 445/TCP 开放，可先验证是否允许空会话列举共享。该测试不包含口令猜测，也不写入文件。出现共享列表时，需要进一步让系统负责人确认其业务用途和访问控制。

SMB_HOST='10.20.30.20'

smbclient -L "//${SMB_HOST}" -N \
  --option='client min protocol=SMB2' \
  2>&1 | tee evidence/${CASE_ID}/raw/smb-anonymous.txt

sudo nmap -p445 --script smb-protocols,smb2-security-mode \
  --script-timeout 20s \
  -oA evidence/${CASE_ID}/raw/smb-config "${SMB_HOST}"

需要关注匿名访问、SMBv1、签名是否强制以及共享目录是否超出必要范围。脚本结果中的“签名未强制”表示中继风险条件之一，但是否能形成完整攻击链，还取决于认证方式、网络位置和其他防护措施，报告中应避免夸大。

结果复核与证据留存

建议保留开始时间、结束时间、执行主机、源地址、工具版本、完整命令和原始输出。证据文件可能包含内部地址、域名、证书信息或共享名称，应限制读取权限并计算哈希。

date -Is | tee evidence/${CASE_ID}/notes/end-time.txt
ip -brief address | tee evidence/${CASE_ID}/notes/source-address.txt
chmod -R go-rwx evidence/${CASE_ID}
find evidence/${CASE_ID} -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > evidence/${CASE_ID}/SHA256SUMS

tar --numeric-owner -czf "${CASE_ID}-evidence.tar.gz" evidence/${CASE_ID}

如果需要让防守方关联日志，应同步记录统一时区和源地址。常见留痕位置包括防火墙会话日志、IDS/IPS 告警、Web 访问日志、Windows 安全日志，以及 Linux 的 sshd、审计和反向代理日志。

风险判断与修复建议

• 资产暴露过宽：通过 VLAN、主机防火墙和管理网 ACL 限制 22、445、3389 等管理端口，仅允许堡垒机或指定运维网段访问。
• 服务版本过旧：先核对发行版补丁回移情况，再根据厂商公告升级；不要仅凭横幅版本直接判定存在公开漏洞。
• TLS 配置不当：关闭过时协议和弱密码套件，使用受信任证书，建立证书到期监控，并在确认全站 HTTPS 后启用 HSTS。
• SMB 匿名访问：禁用来宾和空会话，删除无业务必要的共享，按最小权限配置 ACL，并优先强制 SMB 签名和 SMB2/SMB3。
• 日志不可关联：统一 NTP、保留 NAT 前后的源地址映射，为测试窗口建立工单标识，确保原始日志满足复核周期。
• 扫描影响业务：限定速率与并发，对遗留设备单独设定窗口；出现延迟、连接数或错误率异常时立即停止并通知授权联系人。

复测方法

修复后使用相同源地址、相同端口集合和接近的速率复测，避免因测试条件变化得出错误结论。端口关闭应同时核对网络侧 ACL 和主机监听状态；TLS 与 SMB 配置则应重新采集协商结果。复测报告需要同时记录“已修复”“风险降低但仍存在”和“无法复现”三类结论及其证据。

总结

Kali 在授权渗透中的价值不只是工具数量，而是将探测范围、验证动作和证据链控制在可复核的边界内。先确认路由，再低速发现资产，随后按端口做最小化验证，并把原始输出、工具版本和时间信息完整保存，才能让扫描结果真正转化为可执行的修复项。

这类授权内网探测，建议把“发现、验证、留痕”拆开执行，避免一上来全端口加漏洞脚本，既容易漏报，也会给业务和日志分析带来噪声。

1. 先固化授权范围和任务信息

mkdir -p evidence/{commands,nmap,pcap,notes}
date -Is | tee evidence/notes/start_time.txt
printf '%s\n' '授权网段：10.20.0.0/16' '排除：10.20.10.0/24' \
  | tee evidence/notes/scope.txt
script -q -f evidence/commands/session.log

script 可以记录终端输入和输出，但可能连同敏感参数一起落盘，涉及密码、Token 时不要直接写在命令行里。目标清单最好先生成并人工复核，明确排除地址：

nmap -n -sL 10.20.0.0/16 --exclude 10.20.10.0/24 \
  -oN evidence/nmap/target_review.txt

2. 主机发现不要只依赖 ICMP

内网经常禁 ping，可组合 ARP、ICMP 和常见 TCP 探测。ARP 仅适用于本地二层网段：

# 同一二层网段
sudo nmap -n -sn -PR 10.20.1.0/24 \
  -oA evidence/nmap/01_arp_discovery

# 跨网段，采用较克制的探针
sudo nmap -n -sn -PE -PS22,80,443,445,3389 -PA80,443 \
  --max-rate 200 10.20.0.0/16 --exclude 10.20.10.0/24 \
  -oA evidence/nmap/01_routed_discovery

如果网络策略明确屏蔽所有发现探针，不要直接把整个大网段带 -Pn 全端口扫描；应先缩小资产范围，再分批执行。

3. 端口发现与服务验证分两轮

# 第一轮：常见端口，控制并发和重试
sudo nmap -n -sS --top-ports 1000 -T3 --max-retries 2 \
  --max-rate 300 -iL live_hosts.txt \
  -oA evidence/nmap/02_top_ports

# 第二轮：只对已发现端口做版本验证
sudo nmap -n -sV --version-light -T3 \
  -p 22,80,443,445,3389 -iL selected_hosts.txt \
  -oA evidence/nmap/03_service_verify

服务识别建议先用 --version-light。对数据库、中间件、打印设备和老旧工控设备，应进一步降速；不要仅凭端口号判断服务，最终以握手结果、Banner、TLS 证书和资产侧配置交叉确认。

HTTP/HTTPS 可做低影响验证：

curl -kIsS --connect-timeout 5  \
  | tee evidence/notes/10.20.1.15_https_headers.txt

openssl s_client -connect 10.20.1.15:443 \
  -servername intranet.example.local </dev/null 2>&1 \
  | tee evidence/notes/10.20.1.15_tls.txt

NSE 脚本应显式限定在信息收集类，避免直接使用宽泛的 -sC 或 vuln 分类：

sudo nmap -n -sV -p80,443 \
  --script http-title,http-headers,ssl-cert,ssl-enum-ciphers \
  --script-timeout 20s 10.20.1.15 \
  -oA evidence/nmap/04_http_tls_check

4. 日志留痕不仅保存扫描结果

-oA 会同时保留普通文本、XML 和 grepable 格式，便于复核与后续解析。建议再记录工具版本、出口地址、原始报文和文件哈希：

nmap --version | tee evidence/notes/tool_versions.txt
ip -br addr | tee evidence/notes/scanner_interfaces.txt
ip route | tee evidence/notes/scanner_routes.txt

sudo tcpdump -i eth0 -nn -s 0 \
  -w evidence/pcap/scan_$(date +%Y%m%d_%H%M%S).pcap \
  'net 10.20.0.0/16'

find evidence -type f -print0 | sort -z | xargs -0 sha256sum \
  > evidence/SHA256SUMS

tcpdump 应与扫描任务同时启停，并限制抓取范围；PCAP、XML 和终端日志可能包含内部地址、主机名及证书信息，归档时要设置访问权限和保留周期。

最后，扫描结果里的 open|filtered、版本猜测和脚本结论都应标为“待验证”，不要直接当成漏洞结论。比较实用的交付字段是：目标、时间、源地址、探测方式、端口状态、服务证据、影响说明、原始证据路径和复核结果。