拿到一台主机的渗透shell，只是渗透刚进了门。真正的渗透活儿，从post渗透才算开始。渗透

很多人把提权当成终点。渗透拿到root，渗透截个图，渗透收工。渗透这种习惯很危险——你只是渗透证明了能进去，但没证明能造成多大破坏。渗透客户要的渗透不是你翻墙进去的截图，是渗透你到底能拿走什么。

我习惯在提权之后先做三件事：看网络拓扑、渗透找凭据、渗透摸清业务逻辑。渗透顺序可以乱，但这三件事决定了你这次渗透的深度。

先说网络拓扑。一台web服务器往往不是孤岛。`arp -a`、`netstat -rn`、`cat /etc/hosts`，这几条命令下去，内网轮廓基本出来了。有一次我拿到一台DMZ区的Nginx，路由表里赫然写着`10.0.0.0/8`走内网网关。顺着这条线，用frp搭了个socks5代理进去，三个小时后域控的IP就躺在我的笔记里了。如果当时只满足于web目录下的flag，这条路径永远不会被发现。

凭据收集更考验耐心。浏览器保存的密码、配置文件里的明文、数据库连接字符串、SSH私钥、甚至`.bash_history`里敲过的命令——这些都是金矿。我见过运维把MySQL的root密码写在`/etc/nginx/nginx.conf`的注释里，也见过开发在Jenkins的构建脚本中硬编码AWS的Access Key。拿到这些之后，横向移动就是顺水推舟的事。有个小技巧：`grep -r "password" /var/www/ --include="*.php"`，这条命令帮我找到过至少五个生产环境的数据库口令。

业务逻辑这块最容易被忽略，但往往价值最高。你拿到了数据库的root，能读所有表，这没错。但如果你不理解这些表之间的关联，不知道哪个字段是订单金额、哪个是用户余额，你就没法证明数据泄露的真实影响。我曾经花了一个下午读某电商系统的代码，理清了优惠券的核销逻辑，最后用一条SQL就把所有未使用的优惠券批量标记为已使用——这比脱库更能说明问题。客户看到的是业务中断，不是数据泄露，两者的修复优先级完全不同。

持久化这事得看场景。红队演练里，你需要在目标网络里活得够久，那就得做后门。计划任务、SSH key、webshell、甚至修改PAM模块——手段很多。但如果是正规的渗透测试，我通常只留一个低权限的webshell作为备用入口，测试结束后主动清理。留后门这事，分寸感很重要。

清理痕迹是另一个容易被忽视的环节。你改了哪些文件、创建了哪些用户、写了哪些日志，自己得心里有数。`last`、`lastlog`、`/var/log/auth.log`、`~/.bash_history`，这些地方都得过一遍。不是为了逃避检测，是为了不给客户留烂摊子。我见过有人渗透完不清理，客户第二天发现服务器上多了个叫“hacker”的用户，直接报警了。

报告是post渗透的最终交付物。别堆砌工具输出，那玩意儿没人看。写清楚三件事：你从哪进来的、你在里面干了什么、这些事对业务意味着什么。截图要带时间戳和IP，命令要贴原始输出，风险等级要跟业务影响挂钩。一份好的报告，能让不懂技术的管理层看懂“为什么这事严重”，也能让技术团队知道“具体怎么修”。

说到底，post渗透的核心不是技术，是判断力。知道什么时候该深入、什么时候该收手、哪些数据能碰、哪些不能碰。工具谁都会用，但分寸感这东西，得靠经验堆。