很多人第一次打这类练习靶机，流程都惊人的一致：开机、扫端口、看到服务版本就往搜索引擎里贴，找到一个能跑的利用脚本，脚本回连成功，截个图，关机，换下一台。整套动作行云流水，熟练的话二十分钟能走完一轮。我也这么干过很长一段时间，直到有一次帮人复盘他的练习记录，我问他"这台机器上跑着几个服务，哪个服务的配置最松，你走的这条路为什么能通"，他卡了半分钟没答上来。那一刻我才意识到，靶机实战的价值根本不在那个 shell，而在于你对一台陌生系统从"完全不了解"到"能画出它的结构图"的这个过程。系统篇要练的就是这个过程——操作系统层面的账户、服务、权限、配置、内核，这些东西构成了后面所有 Web 篇、内网篇的地基。地基不牢，你打十台机器也只是记住了十个套路。这篇就把系统层的完整链路拆开讲：环境怎么摆、信息怎么收、口子怎么定、提权怎么走、练完怎么沉淀。
1. 系统篇的第一课不是攻击，是先把靶机"摆正"
1.1 本地靶机跟真实授权环境的差别在哪
先把定位说清楚，不然练法会跑偏。练习靶机是为了教学而设计的，它的漏洞是刻意留出来的：某个服务版本停在好几年前，某个共享目录默认允许匿名读写，某个账户的密码就是用户名本身。这种"人为布置"的好处是路径清晰、可复现，坏处是它会把你的直觉养坏——你会习惯性地认为"扫出来的旧版本就一定能打"、"看到共享就去连一下试试"，而真实授权环境里这两条大概率都不成立。
我自己的调整办法是把靶机从"题库"重新定义成"假设验证沙盒"。什么意思？你在靶机上做的每一个动作，都应该先有一个明确的假设，然后用最小代价去验证它。比如你看到某个服务的版本号偏老，正确的动作不是立刻去搜利用代码，而是先在脑内过一遍：这个版本对应的功能模块是什么，靶机大概率在哪个配置文件里开了这个模块，我能不能用一条无害的请求把它的行为特征抓出来确认。这条链路走通了，你对这个服务的理解就是可迁移的；直接抄 payload，换个版本你就废了。
还有一点需要提前接受：靶机的"噪音"极少。没有防火墙策略、没有终端防护、没有运维半夜改配置、没有业务流量干扰。这意味着你的扫描结果会异常干净，攻击成功率会异常高。等你回到真实授权环境，同样的操作可能连端口都扫不全。所以练习的时候要有意识地给自己加约束，比如限制扫描速率、只允许自己用三条命令确认一个结论、禁止一次性把所有枚举脚本全跑一遍——这些自我约束才是把靶机经验迁移到实战的桥梁。
1.2 网络隔离与快照：两个省下无数麻烦的习惯
环境搭建这块，真正容易出问题的不是装系统，而是网络和回滚。我见过太多人把靶机网卡设成桥接模式直接接到家里的局域网，然后一边扫一边心里发虚。正确做法很简单：攻击机（你自己那台测试用虚拟机）和靶机放在同一个仅主机模式或独立的虚拟内网网段里，跟你的日常网络物理隔开。这样你无论怎么折腾，影响范围都锁死在这两台虚拟机之间。
提示：靶机镜像里往往内置了一些刻意留下的脆弱服务，这些服务本身就不该暴露在任何非隔离网络中。开机前先确认虚拟网络类型，再点启动，这个顺序别反。
快照策略我踩过坑，值得单独说。新手通常只在"开机前"打一个快照，结果打到一半把系统搞崩了（比如误删了某个关键配置文件、或者提权脚本把 sudoers 改坏了），回滚之后又得从头扫一遍。我的习惯是分阶段打快照，并且命名带阶段编号和时间：
| 快照名称 | 触发时机 | 回滚用途 |
|---|---|---|
| s0-clean | 镜像首次开机、未做任何操作 | 完全重来 |
| s1-recon | 信息收集完成、尚未发起任何利用 | 反复验证收集结论 |
| s2-foothold | 拿到初始低权限 shell 后 | 提权失败时快速复位 |
| s3-root | 提权成功后 | 对比前后权限差异、整理证据 |
这个习惯还有个隐性好处：分阶段快照逼着你在每个阶段结束时做一次小结，问自己"我现在掌握了什么、下一步的最小目标是哪个"。这个自问自答的动作，比任何方法论都管用。
虚拟机资源分配上，系统篇的靶机负载其实不高，2 核 2G 内存、20G 磁盘足够跑，攻击机给 4 核 4G 更舒服一点（你要同时开扫描、开终端、开笔记）。磁盘别用精简置备以外的花活，快照多了会吃空间，留 60G 以上比较从容。
2. 信息收集的三层漏斗：从"能不能连上"到"能登进去"
2.1 第一层：存活判定与端口全量扫描
信息收集我习惯按"漏斗"来做，三层，每层只回答一个问题。第一层只回答"这台机器活着吗、它对外开了哪些门"。听起来简单，但这里有第一个高频错误：只扫常用端口。很多人图快，只跑 top 1000 端口，结果漏掉了开在 8080、8443、2222、13306 这类高位端口上的服务，然后卡在那里说"这机器打不动"。系统篇的靶机尤其喜欢把"真正好打的服务"放在非标准端口上，就是要考你会不会做全量。
全端口扫描的代价是时间。一万个端口在本地内网其实很快，关键是参数要给对：
# 全端口发现阶段：只关心哪些端口开着，不做版本识别 scan -p- --min-rate 800 -oA stage1_fulltcp 10.20.30.40 # 针对开放端口做服务与版本识别，比全量扫版本快得多 scan -sV -sC -p 22,80,111,139,445,2049,8080 -oA stage2_service 10.20.30.40两步分开的理由很实在：全端口扫描加版本识别会把时间拉长十倍以上，而第一阶段的输出你只需要一份端口清单。先拿清单，再对清单做精细识别，这是最省时间的顺序。
存活判定这块要留个心眼。很多靶机会屏蔽 ICMP，你 ping 不通不代表机器死了。判断存活更可靠的方式是看 ARP 表（同网段场景下几乎百分百准确），或者直接对目标发一个 TCP 探测看有没有 RST 回来。我一般的顺序是：先看同网段 ARP 有没有新条目，没有再用 TCP 探测确认，两者都否定才下"目标不在线"的结论。
扫描结果整理成一张表，后面每一步都对着这张表走：
| 端口 | 协议 | 服务 | 版本线索 | 优先关注度 |
|---|---|---|---|---|
| 22 | TCP | 远程登录 | 版本偏旧 | 高（有凭据就能直接进） |
| 139/445 | TCP | 文件共享 | 老版本协议栈 | 极高（匿名访问、空会话） |
| 111/2049 | TCP | 网络文件系统 | 导出列表可读 | 高（常能直接挂载） |
| 8080 | TCP | 管理控制台 | 默认凭据可能未改 | 中（看是否暴露配置） |
2.2 第二层：服务指纹、版本号与"过时"的判定
第二层回答"这些门后面站的是谁、什么版本"。这一步是系统篇最容易产生错觉的地方，必须重点讲。
版本号偏旧，不等于存在可利用缺陷。这个不等式后面至少有三道坎：第一，靶机可能已经打了补丁但没改 banner；第二，该功能模块可能被配置禁用；第三，编译选项或运行环境让利用条件不成立。我吃过一次亏，某个服务版本对照公开信息看是"有问题"的，我花了四十分钟反复尝试，最后发现那台机器上的对应模块在配置文件里被显式关掉了，日志里全是拒绝记录。
所以我的做法是三重交叉验证：版本号 + 配置 + 行为特征。版本号告诉你"理论上应该有什么"，配置文件（如果你能读到）告诉你"实际开了什么"，行为特征（发一个无害请求看响应）告诉你"真实运行的是什么"。三者一致，才动手。
抓 banner 的时候也别太信任它。有些服务的 banner 是可以被配置成任意字符串的，靶机设计者甚至故意写个假版本号来钓鱼。我见过最坑的一种情况：banner 显示一个非常老的版本，你以为捡到宝，实际上是设计者留的一个诱饵，目的是让你把时间浪费在一条走不通的路上。判断 banner 真伪的笨办法很有效——去看这个服务的默认错误页、默认目录结构、默认响应头格式，这些细节很难伪造，跟版本号对不上就说明有诈。
服务识别之外，还要抓两类"软信息"：一是服务的启动参数和运行用户（如果通过某个接口能读到进程信息），二是响应中的时间戳和主机名，这些能帮你判断这台机器的角色——是单机练习环境，还是模拟的某台内网业务机。
2.3 第三层：共享目录、账户列表与配置面
第三层回答"有没有不需要突破就能直接拿到的东西"。这一层是系统篇里投入产出比最高的部分，也是最多人跳过的部分。
先说共享。文件共享服务是系统层最经典的入口，原因很简单：它的访问控制经常被配错。枚举的时候按这个顺序走：
- 匿名/空会话能否列出共享列表——能列出就已经成功一半
- 每个共享是否可读——可读就能翻配置、翻备份、翻脚本
- 是否有可写共享——可写意味着后面能走"投毒"路线（往别人会执行的位置放东西）
- 网络文件系统的导出列表——很多练习靶机会把整个家目录导出来，还带
no_root_squash这种宽松选项
再说账户。能拿到用户名列表，后面的口令尝试才有意义（否则你连猜谁都不知道）。账户信息的来源有好几个：共享目录里的用户家目录名、配置文件里的服务账户、某些协议的空会话枚举接口、甚至日志文件里泄露的登录记录。
配置面是最容易被忽略的一块。我养成了一个固定习惯：拿到任何可读目录，先找这几类文件——带conf、config、bak、old、save、sql后缀的，以及任何名字里带backup、setup、install的。这些文件里出现明文凭据的概率高到离谱，而且这属于"靶机设计者希望你找到"的路径，不是运气。
# 在可读共享里快速定位高价值文件 find /mnt/share -type f \( -name "*.conf" -o -name "*.bak" -o -name "*.old" -o -name "*.sql" \) 2>/dev/null grep -rIl -E "password|passwd|pwd|secret|key" /mnt/share 2>/dev/null | head -303. 系统层四个高频突破口，以及它们各自的判断依据
3.1 弱口令与默认账户：永远先试，但要学会有序地试
弱口令在系统篇的地位很特殊——它成功率最高，但最没技术含量，所以很多人要么不屑于试，要么无脑猛试。我的看法是：必须试，但要有序地试，把"试"本身变成一个可解释的过程。
有序的意思是分层。第一层是产品默认账户：很多服务出厂自带管理账户，靶机设计者经常忘了改。第二层是用户名即密码 / 密码即用户名这类极弱组合。第三层是基于已知信息的变形：你从共享目录里翻到了用户名backup，那backup123、backup2023、Backup@123这类就该进字典。第四层才是通用弱口令字典。
这样分层的好处是，即使前三层都没中，你也已经把目标的"人员习惯"摸清了一部分，第四层的字典可以针对性裁剪，效率比一把梭高得多。
注意：在真实授权环境里做口令尝试前，必须先确认账户锁定策略和业务影响窗口，否则很容易把运维账户锁死，造成实际业务中断。靶机上没有这个顾虑，但这个习惯要在靶机上就养起来，别等出了问题才想起。
口令尝试还有个体面的判断标准：你是在验证一个假设，还是在碰运气。如果你能说清楚"我猜这个账户的密码是某个已知信息的变形，因为这台机器的部署脚本里出现过类似的命名习惯"，那就是在验证；如果你只是把五万行字典往里灌，那就是碰运气，哪怕成功了也学不到东西。
3.2 过时服务与已知缺陷：版本比对的价值与陷阱
这一条是系统篇的主线，也是坑最多的地方。价值在于：过时服务往往带着一整套已经公开的行为特征，你能快速判断"该往哪个方向打"。陷阱在于：从"版本过时"到"能打穿"之间隔着一堆条件。
我自己的判断流程是这样的，四步，每步都可以中止：
| 步骤 | 要确认的事 | 中止条件 |
|---|---|---|
| 1 | 版本号是否真实（banner 是否可伪造） | banner 与默认指纹不符则降权处理 |
| 2 | 触发缺陷的功能模块是否启用 | 配置文件或响应表明模块关闭，直接放弃这条路 |
| 3 | 服务运行在什么权限下 | 服务本身已是低权限，即使打通也没提权价值 |
| 4 | 该缺陷的利用条件是否在当前环境成立 | 依赖特定库版本、特定编译选项不满足，放弃 |
第三步很多人不看，但它决定了你打通之后是"直接是管理权限"还是"还得再提一次权"，这两条路的后续工作完全不同。
另外提醒一点：不要把所有希望押在一条版本比对结论上。系统篇的靶机通常会在多个位置留口子，版本比对只是其中一条。当你发现这条路的利用条件不成立时，果断换路，别沉没成本驱动。我给自己定的规矩是：单条路径连续尝试超过二十分钟没有实质进展，就强制切到下一层枚举，回头再来。
3.3 文件共享与匿名访问：最被低估的一条路
我把它单拎出来讲，是因为这条路的"性价比"高得不像话，但在新手那里经常被跳过。原因大概是它看起来"太简单了"，不像攻击。
典型链路是这样的：文件共享服务允许匿名读取 → 里面有一个部署备份目录 → 备份里有一个应用的配置文件 → 配置文件里有数据库连接串或者某个服务账户的明文密码 → 这个账户恰好也是系统登录账户 → 直接登录拿到 shell。整条链路不需要写一行利用代码，但它完完整整地体现了系统层渗透的核心逻辑：凭据的流动。
配置这条链路的关键判断点有两个。第一，你要能识别"这个文件值不值得细看"。我的经验是看修改时间和文件大小——部署备份通常时间戳集中在某个时刻，大小在几百 K 到几 M 之间，太小的多半是占位文件。第二，你要能判断"这个凭据能用到哪"。拿到一个用户名密码组合后，要挨个试它可能适用的入口：系统远程登录、数据库、管理控制台、其他共享。同一个凭据在多处复用是极常见的情况。
# 匿名枚举共享（示例，工具名占位为 smbcli） smbcli -L //10.20.30.40 -N smbcli //10.20.30.40/backup -N -c 'recurse ON; prompt OFF; mget *' # 网络文件系统的导出列表与挂载 showmount -e 10.20.30.40 mount -t nfs 10.20.30.40:/export/home /mnt/nfs挂载之后要立刻检查一件事：你在这个挂载点上创建的文件，属主是谁。如果属主是远端的高权限用户，说明导出配置很宽松，这条路后面能延伸出"投毒"手法，价值直接翻倍。
3.4 权限配置失误：从"能读"到"能写"的那一步
权限配置失误是系统层最有"技术味"的一类突破口，因为它要求你真正看懂系统的权限模型。类 Unix 系统上要盯的主要是这几样：
- 带 SUID/SGID 位的可执行文件：某个可执行文件带了 SUID 位又以高权限运行，如果它内部调用了能被外部影响的东西，就能借道提权
- 可写的定时任务脚本：定时任务以高权限运行，脚本本身却对普通用户可写，直接替换内容即可
- 可写的服务配置或服务加载目录：服务重启时会读取这些路径
- 以高权限运行的可写脚本：某服务以管理权限运行一个位于可写目录的脚本
判断顺序上，我建议先查"可写的定时任务"和"可写的服务配置"，再查 SUID。理由是前两者的成功条件更直接——"我能写，它会被执行，它执行时是高层权限"，三个条件一目了然；SUID 还需要额外的分析，判断成本更高。
# 系统层权限面的手工排查（类 Unix） find / -perm -4000 -type f 2>/dev/null # SUID find / -perm -2000 -type f 2>/dev/null # SGID find / -writable -type f -name "*.sh" 2>/dev/null | head # 可写脚本 ls -la /etc/cron* /var/spool/cron 2>/dev/null # 定时任务 sudo -l 2>/dev/null # 当前用户可用命令这套命令手工跑一遍大概三分钟，比跑一个全自动枚举脚本收获更清楚。自动化脚本的问题不是不准，而是输出太吵——几百行结果糊在屏幕上，你根本不知道该先看哪个。我的做法是手工先跑一轮建立整体印象，再用脚本查漏补缺，顺序不能反。
4. 拿到初始 shell 之后：提权是一条信息链，不是一次尝试
4.1 先固化信息，再谈动手
新手拿到低权限 shell 之后的第一反应通常是"赶紧找提权"。这个顺序是反的。正确的第一步是固化信息——把当前环境的完整状态记录一遍，存到你自己那边，然后再基于这份记录做判断。
为什么？因为提权过程中你很可能会把环境搞乱（比如改坏了某个配置文件、触发了某个服务异常），一旦环境变了，你之前观察到的信息全部失效，而你又没有备份，只能回滚重来。固化信息的成本是五分钟，能省下的重来成本是半小时起步。
要固化的内容我列成了一张固定清单，每次照着打一遍：
| 类别 | 具体内容 | 看什么 |
|---|---|---|
| 身份 | 当前用户、用户组、可切换身份 | 有没有意外的组成员关系 |
| 系统 | 内核版本、发行版版本、架构 | 是否落在某个已知问题区间 |
| 账户 | 可读的账户与组文件、家目录权限 | 有没有其他用户的敏感文件可读 |
| 权限 | SUID/SGID 清单、可用提权命令、文件能力位 | 提权路径的第一手线索 |
| 进程 | 以高权限运行的进程及其命令行、可执行文件路径 | 有没有运行在可写目录里的进程 |
| 定时 | 全系统的定时任务配置 | 有没有对当前用户可写的任务脚本 |
| 网络 | 本机监听端口、内部可达网段 | 有没有只对内开放的服务 |
| 挂载 | 挂载表与各挂载点权限 | 有没有宽松挂载 |
# 快速固化（类 Unix 低权限 shell） ( id; uname -a; cat /etc/os-release ) > /tmp/note.txt 2>&1 ( cat /etc/passwd; cat /etc/group ) >> /tmp/note.txt 2>&1 ( ps aux 2>/dev/null || ps -ef ) >> /tmp/note.txt 2>&1 ( ss -tunlp 2>/dev/null; mount ) >> /tmp/note.txt 2>&1 # 记得把结果取回本地，不要只留在靶机上4.2 提权路径的四大类与它们的检查顺序
系统层提权，翻来覆去就四类，把分类记清比记具体手法有用得多：
第一类，配置失误。SUID 配置不当、定时任务可写、服务配置可改、可提权命令被过度授权。这类成功率最高、对系统影响最小，永远第一个查。
第二类，凭据泄露。配置文件里的明文密码、历史命令记录里的密码、备份里的密钥、其他用户家目录里可读的私钥。这类不需要"打"，只需要"找"，找到就是你的。
第三类，服务以高权限运行。某个后台服务以管理权限跑，而它读取的文件、监听的接口、依赖的库位于你能影响的位置。这类需要你对服务的运行机制有理解，难度中等。
第四类，内核或系统组件的已知问题。这类最"刺激"但风险最大，因为通常会导致系统不稳定。放在最后查，而且只在前面三类全部走不通时才考虑。
检查顺序就是上面这个顺序，不是随便排的。逻辑是：从"影响小、成功率高"排到"影响大、成功率低"。这个排序背后是一个很实在的工程经验——在真实授权环境里，你需要的是"最快拿到最高权限且不惊动业务"，而不是"用最酷的方式拿到权限"。靶机上没人管你搞崩系统，但习惯要从靶机就开始养。
另外补一句关于信息收集脚本的态度。这类脚本很有用，但它的作用是查漏，不是替代判断。我一般先用它跑一次，把输出对照自己的手工清单，看它发现了什么我没发现的，然后回头搞清楚"为什么我会漏掉这个"。这个过程积累下来，你的手工清单会越来越准，最后你可以不依赖脚本。
4.3 一条完整提权链路的复盘
讲一条我练过很多次的链路，把它当成模板，重点看每一步的判断依据而不是具体命令。
起点：低权限 shell，身份是某个服务账户。
第一步，权限面排查。检查可写文件时，发现某个应用目录下有一批脚本对当前用户可写。这里的关键判断是：可写本身没意义，要确认"这个目录里的东西会不会被执行、由谁执行"。所以接着去看这个目录被哪些进程引用。
第二步，进程关联。进程列表里有一个以高权限运行的后台任务，命令行指向这个目录下的某个脚本。到这里条件基本齐了：我能写、它会被执行、执行时是高权限。
第三步，也是最容易翻车的一步：确认执行时机和触发条件。定时任务有周期，短则一分钟长则一天。如果周期很长，你写完得等很久；更糟的是，如果是个事件触发的任务（比如文件变更触发），你可能永远等不到。所以要先看配置里的周期和触发方式，估算等待时间，再决定要不要走这条路。
第四步，构造内容。这是唯一需要点技术的一步。目标是在不破坏系统可观测性的前提下拿到高权限。手法上我倾向于"最小改动"：创建一份带高权限属性的副本，而不是直接改账户数据库，因为改账户数据库容易留下明显的痕迹，也不利于后面整理证据。
第五步，验证与收拾。执行完立刻验证身份是否变化，然后马上把改动还原。这一步很多人在靶机上不做，但在真实环境里它是必须的，而且它也是你写报告时"影响范围评估"那一节的依据。
# 最小改动的思路示例（类 Unix，仅用于本地隔离靶机） cp /bin/sh /tmp/.legit 2>/dev/null chmod 4755 /tmp/.legit /tmp/.legit -p # 完成后立即还原 rm -f /tmp/.legit整条链路走下来，真正花时间的不是"执行"，而是每一步的条件确认。我的经验是条件确认占七成时间，执行占三成。新手往往反过来，条件没确认清楚就动手，失败了还不知道是条件不满足还是手法不对，只能一遍遍重试，越试越乱。
5. 靶机练完之后，真正拉开差距的收尾动作
5.1 快照、时间线与实验记录
打穿一台靶机，很多人就关机换下一台了。这一步省略掉的，恰恰是最有价值的部分。
我的习惯是每台靶机配一份实验记录，格式很土但很管用，就四列：时间、动作、预期、实际结果。写的时候有个硬要求——"预期"这一列不能空。空着就说明你是在瞎试，而不是在验证。这个要求逼着你在动手前想清楚自己到底在干什么。
时间线还有第二个用途：复盘时能把"运气"和"方法"分开。你把整条路径按时间顺序排开，会清晰地看到哪些环节是计划内的推导，哪些环节是碰巧撞上的。碰巧撞上的那部分，才是你真正要补的短板。我复盘一台机器的时候，通常会问自己三个问题：第一，最早可以走通的那条路，我是什么时候发现的，为什么不是更早？第二，我走了哪些完全无效的弯路，弯路的起因是什么（错误假设、误读输出、漏看信息）？第三，如果给我一台结构类似但服务版本不同的机器，我能不能在半小时内重走一遍？
提示：记录里不要只写成功的路径。失败的尝试、无效的假设、被推翻的结论，这些才是复盘时信息量最大的部分，而且它们往往能解释"为什么我多花了两个小时"。
5.2 报告怎么写才叫"能复现"
靶机练习不需要写正式报告，但我建议每台机器都写一份简短的东西，标准只有一个：另一个人拿着这份材料，能在同样的环境里完整复现你的每一步。
能复现的意思是，每一步都要有"命令/操作 + 原始输出 + 一句话结论"。只说"通过文件共享拿到了凭据"是不够的，要写清楚：在哪个共享、哪个路径、哪个文件、文件里哪一行、拿到的是哪个账户的凭据、这个凭据在哪个入口验证成功。信息粒度到这一层，才叫证据。
报告里必须有的几块内容：
| 板块 | 写什么 | 常见问题 |
|---|---|---|
| 目标与环境 | 靶机地址、服务清单、网络拓扑 | 写了地址但没写网络类型，别人复现不了 |
| 攻击路径图 | 从外部到最终权限的完整节点串联 | 只写了手法，没写节点之间的因果 |
| 分步证据 | 每步的操作、输出、结论 | 只贴结果不贴过程，无法复现 |
| 根因分析 | 这条路径成立的根本原因 | 停在"服务版本旧"，没往下挖到配置层面 |
| 整改建议 | 具体到配置项和操作 | 写成"加强安全管理"这类空话 |
最后一块我要多讲两句，因为它是区分"会打"和"懂"的分水岭。整改建议必须具体到可执行的程度。比如不要写"修复文件共享配置"，而要写"关闭文件共享服务的匿名访问，对共享目录做访问控制列表限制，仅允许指定账户读写，并复核导出配置中的权限映射选项"。这两句话的差距，就是"知道哪里有问题"和"知道该怎么修"的差距。
写建议的过程其实是在反向检验你的理解。如果你只能说出"这里有个漏洞"，说明你只看到了现象；如果你能说清楚"这里的配置为什么会导致这个后果、改成什么样就能阻断这条路径、改完会不会影响正常业务"，说明你真正理解了这台机器的结构。我练系统篇最大的收获，基本都是在这个环节得到的——很多时候写着写着发现自己的根因分析站不住脚，回头再查一遍配置，才发现之前的理解是错的。
我个人在实际操作中的体会是，靶机练到后期，扫端口、找漏洞这些动作会变得非常快，快到几乎不过脑子。这个时候真正要刻意训练的，反而是慢下来的能力——在拿到一个 shell 之后忍住不去直接找提权，先把当前环境的信息完整记录一遍；在发现一条看起来很好走的路之后忍住不立刻动手，先把利用条件逐条确认清楚。这两个"忍住"，比多记十个技巧管用得多。系统篇之所以排在最前面，大概也是这个原因：它练的不是手法，是节奏。
