渗透配置

上周三凌晨两点，我盯着 kali 终端里一行报错：“Exploit completed,渗透配置 but no session was created.” 靶机是台没打补丁的 Windows Server 2012，MS17-010 的渗透配置利用脚本跑得顺风顺水，可 shell 死活弹不回来。渗透配置折腾了四十分钟，渗透配置最后发现是渗透配置目标出站防火墙拦了 4444 端口。换到 443，渗透配置秒上线。渗透配置这事儿跟技术多牛没关系——渗透测试里，渗透配置配置比漏洞本身更能决定成败。渗透配置

很多人把“渗透”想象成敲几行命令、渗透配置等一个 root shell 的渗透配置爽文剧情。真实情况是渗透配置，你大部分时间都在跟各种配置文件、渗透配置网络策略、渗透配置编码格式较劲。一个反向 shell 能不能连回来，不取决于你用的 payload 多花哨，而取决于目标机器能不能把包发到你指定的 IP 和端口。这听起来像废话，但新手最容易栽在这儿。

上面这段命令，LHOST 填的是你攻击机的 IP，LPORT 是你监听的端口。问题来了：如果你在云服务器上跑 Kali，LHOST 就不能填内网地址，得填公网 IP。可有些云厂商的 NAT 是双向的，你填了公网 IP，包反而绕不回来。我见过有人在这卡了一整天，最后发现是安全组没放行 443 入站。这种坑，教程里通常一笔带过，实战里却能让你怀疑人生。

再说个更隐蔽的。Windows 的 Defender 对 reverse_tcp 的查杀已经到行为特征级别了。你生成的 exe 可能刚落地就被删，或者运行后弹个“操作已被阻止”。这时候就得换 reverse_https，把流量伪装成正常的 Web 请求。但 HTTPS 证书又是个坑——自签名证书在 meterpreter 里得额外设置 StagerVerifySSLCert=false，否则 stager 连不上。你看，光一个 payload 传输，就能扯出证书、编码、端口复用一堆配置。

“渗透的本质是信息收集，但信息收集的终点，是搞明白目标允许什么流量出去。”——这话是我一个做红队的朋友说的，糙理不糙。

内网横向移动更是配置的重灾区。你拿下一台 Web 服务器，想用 psexec 打域控，结果发现 445 端口被 IPS 封了。换 wmiexec 走 135 端口，又碰上 WMI 服务没开。最后用 winrm 走 5985，还得先确认目标机器启用了 WinRM 且允许非加密连接。每一步都是配置检查，每一步都可能断链。我习惯在拿下一台机器后，先跑一遍 netstat -ano 和 netsh advfirewall show allprofiles，把出站规则摸清楚再动手。这比盲目扔 exp 效率高得多。

还有编码问题。Linux 靶机上弹个 shell，中文路径乱码；Windows 上执行命令，输出里混着 UTF-16 的 BOM 头。这些不影响 getshell，但影响你后续操作。配置 chcp 65001 或者用 iconv 转一下，能省下大量抓狂时间。细节不致命，但恶心人。

说回开头那台 2012。后来我复盘，其实 show options 里早就提示 LPORT 可能被过滤，只是我没细看。渗透工具把太多东西自动化了，反而让人忽略最基础的网络配置。现在每次开打之前，我都会先问自己三个问题：目标能出什么端口？我的监听地址对不对？payload 的编码能不能过 AV？这三个问题的答案，基本决定了这次渗透是十分钟收工还是通宵白干。

配置这东西，没有标准答案。同一个漏洞，在不同网络环境里需要不同的参数组合。多踩几次坑，自然就形成肌肉记忆了。下次再遇到 no session，别急着换 exp，先 tcpdump 抓个包看看——十有八九，问题出在你没注意的那个配置项上。