后渗透攻击

拿到一台机器的后渗 shell 只是开始，真正决定一次攻击能走多远的透攻，是后渗后渗透阶段做了什么。很多人把提权当成终点，透攻实际上那只是后渗打开了另一扇门。真正的透攻战场在门后面——域控、数据库、后渗备份服务器、透攻运维跳板机，后渗这些东西不会因为你拿到了一个 webshell 就自动暴露出来。透攻

我见过一次典型的后渗案例。攻击者通过一个未打补丁的透攻 Confluence 拿到了 Tomcat 权限，系统是后渗 Ubuntu 18.04，www-data 用户。透攻常规操作：上传 linpeas，后渗跑一遍，发现内核版本是 4.15.0-99，脏牛可用。提权到 root，整个过程不到二十分钟。到这里，很多人的渗透报告就可以收尾了。但那天攻击者没停。他在 /root 目录下翻到一个 .bash_history，里面有一条命令：ssh -i /root/.ssh/id_rsa_backup deploy@10.0.3.45。私钥还在，目标是一台内网部署机。这就是后渗透的入口。

横向移动的关键不在于工具多花哨，而在于信息收集够不够细。攻击者用 impacket 的 psexec 试了那台部署机，失败——对方没开 445。换用 ssh 加私钥，成功登录。部署机上跑着 Jenkins，配置里明文存着 GitLab 的 root token 和一台生产数据库的连接串。到这里，攻击面从一台边缘 Web 服务器扩展到了整个代码仓库和生产数据。

权限维持这件事，很多人做得太糙。直接写 crontab 反弹 shell，或者丢一个 meterpreter 的 persistence 脚本。这些在应急响应里活不过一轮排查。更隐蔽的做法是滥用现有服务。比如那台部署机上有个 systemd timer，每小时跑一次 rsync 同步脚本。攻击者把脚本内容改了一行，加了个 base64 编码的 curl 请求，指向自己的 C2。文件时间戳用 touch -r 对齐原文件，权限不变。这种改动不会触发文件完整性监控，因为脚本本身就在白名单里。

凭据收集是后渗透里回报率最高的动作。Windows 域环境里，Mimikatz 抓 lsass 内存能拿到明文或 NTLM hash，但前提是你有本地管理员权限。更隐蔽的方式是翻注册表里的自动登录凭据、组策略首选项里的 cpassword、IIS 的 applicationHost.config 里的连接串。Linux 侧除了 .bash_history 和 .ssh，还要看 /etc/fstab 里的挂载凭据、Docker 的 config.json、Kubernetes 的 service account token。这些东西不需要提权就能读，但价值往往比一个 root shell 还大。

数据外传要控制节奏。一次性打包几百 G 的数据库，流量监控立刻告警。分批次、走合法通道、伪装成正常业务请求，才是稳妥做法。用 DNS 隧道传小文件，用 HTTPS 上传到云存储的合法域名，甚至直接通过已登录的 OA 系统导出报表——这些操作在日志里看起来就是普通用户行为。

清理痕迹不是删日志那么简单。Linux 下 utmp、wtmp、btmp 三个文件记录登录会话，直接清空会留下明显空文件，用 utmpdump 回写伪造记录更合理。Windows 事件日志用 wevtutil 清会留 ID 1102，不如针对性地删掉特定事件 ID。命令历史用 history -c 只是清当前会话，.bash_history 里的旧记录还在。最稳妥的方式是全程用不带 history 的 shell，或者把 HISTFILE 指向 /dev/null。

后渗透的本质是信息不对称的持续利用。拿到一个凭据就去试十个地方，发现一个配置文件就翻三遍。攻击链的深度不取决于漏洞数量，取决于你对手里那点权限的理解有多深。一个 www-data 能读 /etc/passwd，能看 /proc 下的环境变量，能连内网数据库——这些小事串起来，就是一条通往核心的路。