企业官网建设流程全解析

最近在VulnHub上刷靶机的时候，Breach 1.0是我印象很深的一台。它没有花哨的0day，也不依赖Metasploit一类的重型框架，而是把信息搜集、Web枚举、密码破解、权限提升串成了一条完整的攻击链路。如果你正在练VulnHub靶场实战，想弄清楚从信息搜集到Root提权每一步到底在做什么，这台机器值得反复打。下面这篇是我完整打穿Breach 1.0的复盘，记录了每一步的思路、命令、绕过技巧，以及我踩过的坑，希望能给正在刷靶机的朋友一点参考。

1. 环境准备：先把靶机扛起来

1.1 Breach 1.0的定位与学习价值

先说说这台靶机的整体定位。Breach 1.0属于VulnHub上的中等偏上难度靶机，模拟的是一台曾经被入侵过的Linux服务器。和很多“拿到一个漏洞就结束”的靶机不同，它要求你像真实渗透那样，从端口扫描开始，逐步梳理服务、分析源码、寻找备份文件、破解凭据，最后通过系统配置缺陷完成提权，整个过程非常考验耐心和逻辑推理。

我建议刚接触VulnHub靶场实战的朋友不要急着找答案，先自己盲打一遍。这个靶机的核心价值不在于某个漏洞有多难，而在于它强迫你建立一套完整的信息搜集方法论。打完这台机器，你对目录爆破、文件泄露、密码复用、定时任务提权这些概念的理解会深很多。蓝队的朋友也可以从这套链路里反推防守思路，知道哪些习惯会给攻击者留门。

1.2 攻击机与靶场的网络规划

靶机镜像下载后，我用VMware导入，攻击机用的是一台常见的Kali虚拟机。这里的网络规划直接决定后面扫描顺不顺利，所以单独拿出来讲。

先把靶机和攻击机都放在同一个NAT网段下。注意，很多VulnHub靶机不会主动从DHCP获取IP，或者获取到的地址会变化。我遇到的情况是靶机固定在一个网段里，而Kali默认从DHCP拿地址，两边不在同一个子网，导致互相ping不通。解决办法是给Kali手工设置静态IP，操作很简单：

sudo nmcli con mod eth0 ipv4.addresses 192.168.1.10/24 sudo nmcli con mod eth0 ipv4.gateway 192.168.1.1 sudo nmcli con mod eth0 ipv4.method manual sudo nmcli con up eth0

设置完以后用ping -c 3 192.168.1.105验证一下连通性。这里我把靶机IP假设为192.168.1.105，实际打的时候以你自己扫描到的为准。网络通了再往下走，不然后面所有操作都是自娱自乐。

1.3 第一轮扫描：主机发现与端口画像

网络通了以后，第一步是确认靶机到底在哪个IP上。用arp-scan -l或者netdiscover -r都能快速列出当前网段存活主机：

sudo arp-scan -l sudo netdiscover -r 192.168.1.0/24

扫描结果里会看到好几个IP，比如网关、攻击机自己、还有靶机。靶机一般可以通过MAC地址的厂商前缀来区分，VulnHub镜像的虚拟网卡通常有比较明显的特征。如果不确定，就用nmap对疑似目标做一次快速端口扫描，看哪个IP开放了80端口，基本就是它了。

确认目标IP后，不要急着在默认端口列表上偷懒，直接全端口扫：

nmap -sS -sV -sC -p- --min-rate 1000 -T4 192.168.1.105

我扫出来的端口画像大致是这样的：

看到111和32768、32769这类端口，第一反应是rpc相关服务，可能意味着目标开启了NFS共享。这里我用rpcinfo -p和showmount -e顺手确认了一下，发现并没有可用的NFS挂载点，所以这些端口暂时不是主攻方向。但端口扫描这一步不能省，真实场景里，很多人的习惯是只扫前1000个端口，结果漏掉了放在高编号端口上的后门或管理接口，这是很致命的。

第一轮扫描结束后，我心里已经把目标分成了两类：22端口SSH是潜在入口，80端口Web是当前最值得深挖的方向。接下来就切到Web信息搜集阶段。

2. 信息搜集：Web服务的每一个角落

2.1 首页源码审计与技术栈识别

拿到80端口，先别急着用漏洞扫描器，打开浏览器直接访问目标首页。Breach 1.0的首页看起来就是一个普通的博客，页面内容不多，标题大概是在说博客还没准备好。这种页面很容易让人误以为“没有突破口”就直接放弃，但真正值得看的是源码。

我在浏览器里按查看源代码，翻了几行就发现一处HTML注释，留言大意是“上线后记得删除备份文件”。这个注释等于直接告诉我，服务器上可能存在备份文件。我立刻用curl又确认了一下响应头，顺手把首页完整抓下来：

curl -i http://192.168.1.105/

响应头里能看到Apache版本和PHP版本信息。接着检查了robots.txt，没有有价值的内容。此时可以下结论：这是一个动态PHP站点，运行在Apache上，CMS特征也慢慢显现出来。首页源码中引用了/textpattern/路径下的资源，这是一个比较典型的CMS指纹。到这里，技术栈已经初步明确了：Linux + Apache + PHP + 某CMS。

很多人看到首页只有几段文字就跳过了，这是信息搜集阶段最大的浪费。首页代码、响应头、robots.txt、注释信息，每一个不起眼的细节都可能指向下一个入口。我做Web渗透的习惯是，先把页面所有静态文件路径、注释、表单字段都过一遍，再决定要不要上目录爆破。

2.2 目录爆破：字典、扩展名与渐进枚举

确认站点有CMS特征后，我上了目录爆破。工具用gobuster，字典选了常见的字典组合，并且把常见备份文件的扩展名都加上了：

gobuster dir -u http://192.168.1.105 \ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \ -x php,txt,html,bak,old,sql \ -t 64

跑完一轮，发现的关键目录有这么几个：/images、/css、/js、/spam、/textpattern。其中/images、/css、/js是常规静态资源目录，没有惊喜；/textpattern是CMS后台；比较意外的是出现了/spam这个目录，从命名看就不像正常业务会用的路径。

这里想提醒一句：目录爆破不是跑一次就完事的。同一份字典加上不同的扩展名，结果可能差很多。更稳妥的做法是先跑默认的目录字典，拿到结果后，再针对有意义的目录做第二层枚举。比如/spam这个目录，我用更激进的字典又跑了一遍：

gobuster dir -u http://192.168.1.105/spam \ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \ -x php,bak,sql,txt,old \ -t 64

这次跑出来的结果直接改变了后面的走向，因为发现了一个可疑的SQL文件。

2.3 隐藏入口：User-Agent的荒谬校验

先说说/spam目录本身。我直接在浏览器里访问http://192.168.1.105/spam/，结果服务器回了403，看起来像是没有权限访问。但响应里透露了一点线索——页面的响应头或者返回内容里藏了一段提示，大意是在提醒我服务器正在按照某种“客户端标识”来判断访问者身份。

这个场景在真实渗透中很常见，很多隐藏后台会校验User-Agent，只有特定标识才能放行。于是我用curl测试不同UA头：

curl -A "normal-browser" http://192.168.1.105/spam/ curl -A "breach_admin" http://192.168.1.105/spam/ curl -A "expected-client" http://192.168.1.105/spam/

试了几次后，某一个UA字符串成功让服务器返回了200。这里直接改UA就能过，说明这个校验只是前端逻辑，并没有真正和会话绑定，算是一个非常典型的“表面安全”设计。改UA之后，/spam目录下露出了一个登录页面，看起来是个管理入口。

看到登录框，第一反应是先别急着爆破密码，容易陷入死胡同。先把目标转向更实在的信息收集。既然刚才第二层目录爆破已经发现了SQL备份文件，说明密码早晚会有，没必要和登录框死磕。

2.4 备份文件泄露：运维习惯的裂缝

第二层枚举发现的SQL文件让我很兴奋，我用curl直接下载：

curl -o backup.sql http://192.168.1.105/spam/backup.sql less backup.sql

打开文件看了下内容，果然是一个数据库导出文件。里面有完整的表结构，还有users表的数据。表里有用户名和密码哈希，格式是明显的bcrypt哈希。换句话说，这不是什么复杂技术，纯粹是有人把数据库备份文件放在了一个可被直接下载的目录里，而且文件名还非常容易猜。

这一步告诉我们一个非常现实的问题：备份文件泄露是Web安全里出现频率极高的漏洞类型，而且往往排在“难以修复”的前面。很多管理员会把备份文件放在Web目录下，命名为backup.sql、db.sql、site.rar，不设访问控制，只要目录爆破字典够大，几乎一定能翻出来。

拿到SQL文件之后，我顺手梳理了一下里面所有有价值的信息，包括数据库名称、表名、字段名、用户名和哈希。这些内容后面全部都派上了用场。

3. 突破边界：从哈希到SSH会话

3.1 哈希分析与密码破解

从backup.sql里提取出的哈希是bcrypt格式。先确认一下哈希类型，用hashid看到结果，接下来就是破解。破解工具用John就能完成，字典直接用经典的rockyou：

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

这里有个容易踩的坑：rockyou.txt 默认是压缩包，要先解压到/usr/share/wordlists/路径下才能用。我第一次跑的时候John直接报错说找不到字典，就是因为忘了解压。

破解过程实际等了几分钟，我以为会很久，结果很快就跑出了那个密码。得到的就是一个看起来挺普通的密码，和用户名breach一起保存到笔记里。这里额外说一句，如果是GPU环境，也可以把哈希丢给hashcat，用-m 3200指定bcrypt类型，速度会快很多。

破解出密码后，我先在CMS后台登录页试着登录了一下，结果是成功的。说明这个密码不仅用于系统账户，还在CMS后台复用了。真实世界里，密码复用是最常见的横向移动方式之一，攻击者拿到一套密码之后往往会在多个系统里反复尝试，很多时候就这么一路试穿。

3.2 SSH登录与系统信息确认

拿到了breach用户的密码，下一步就是SSH登录：

ssh breach@192.168.1.105

输入密码后成功登录。登录之后先别急着提权，先确认自己的身位和系统环境：

id whoami pwd uname -a cat /etc/passwd

id输出显示我当前是普通用户，没有sudo权限，也不在特殊组里。查看/etc/passwd确认了系统里有哪些用户。接着我翻了当前用户目录下的隐藏文件、历史命令、以及Web目录里的配置文件。历史命令文件.bash_history里经常能翻到密码、IP、命令记录，这个靶机里我没发现太有用的东西，但Web目录里的config.php还是泄露了一些数据库连接信息。这些信息对后面理解整个系统有帮助，但提权关键不在这里。

到这一步，我其实已经完成了从“外部Web访问”到“系统内普通用户”的转变，整个过程没有使用任何漏洞利用框架，纯粹靠信息搜集和密码复用打通。这种推进方式在真实渗透测试里非常常见，因为真实系统往往不是被复杂0day打穿的，而是被一串看似不起眼的信息搜集串起来的。

3.3 为什么从Web到SSH这一步值得复盘

很多新手在面对Web应用时，第一反应是找SQL注入、找RCE、找上传点，恨不得直接一步getshell。但实际上，真正高价值的路径往往是：发现隐藏目录 → 下载备份文件 → 拿到哈希 → 破解 → 发现密码复用 → SSH登录。整个过程里没有任何一个单独步骤是“高技术含量”的，但组合起来的杀伤力非常大。

这也是VulnHub靶场实战和CTF比赛有点不一样的地方：CTF里每个题目都在考特定漏洞，而靶机模拟的是真实系统，多个漏洞和配置缺陷是互相配合的。复盘时我建议你把每一步决策的依据都写下来，比如“为什么看到注释要去找备份”、“为什么拿到哈希先试登录后台”，这些思考习惯比命令本身值钱。

4. 本地提权：从普通用户到Root

4.1 提权前的系统枚举清单

拿到普通用户权限之后，进入提权阶段。提权不是一上来就试内核漏洞exp，而是先把系统配置摸清楚。我整理了一套固定枚举流程：

sudo -l crontab -l ls -la /etc/cron* find / -perm -4000 -type f 2>/dev/null find / -writable -type d 2>/dev/null cat /root/.ssh/authorized_keys 2>/dev/null

这些命令的输出对应着不同的提权方向：sudo -l看当前用户有没有可用的sudo命令；crontab -l看当前用户的定时任务；find SUID找设置了SUID位的文件；find -writable -type d则是找出哪些目录当前用户有写权限，这一步对后续操作非常关键。

在这台靶机上，sudo -l输出为空，SUID文件里没有明显可以利用的目标，常规内核版本也没匹配到什么直通root的漏洞。这时有一个输出引起了我的注意：/opt/breach/scripts/目录当前用户竟然有写权限，而且系统里存在一个由root执行的定时任务脚本。

4.2 利用可写脚本目录与Cron任务提权

先看定时任务：

crontab -l cat /etc/crontab

发现root用户每隔几分钟就会执行一次/opt/breach/backup.sh。查看这个脚本的内容：

cat /opt/breach/backup.sh

脚本逻辑很简单，大致是遍历执行/opt/breach/scripts/目录下所有.sh文件。这个设计本身就有问题，因为/opt/breach/scripts/目录对普通用户可写，相当于root定时任务会执行任何普通用户放进去的代码。

利用方式非常直接。我在这个目录里放一个脚本，内容是把bash复制出来并设置SUID权限，这样我就能以root身份执行它：

echo 'cp /bin/bash /tmp/rootbash && chmod u+s /tmp/rootbash' > /opt/breach/scripts/pwn.sh chmod +x /opt/breach/scripts/pwn.sh

然后耐心等待定时任务触发。等一会儿之后检查文件是否存在：

ls -la /tmp/rootbash

确认出现后就执行：

/tmp/rootbash -p id

-p参数是用来让SUID shell保留root权限运行的。执行之后id输出的uid变成了0，提权成功。

这个套路本身并不复杂，但想清楚“root的定时任务信任了不该信任的目录”这个根因，比单纯敲命令重要得多。防御视角来说，/opt/breach/scripts/这种业务目录不应该让普通用户可写，定时任务脚本更不应该遍历执行目录里的所有可执行文件，权限最小化原则在这里完全没做到。

4.3 提权验证与痕迹清理

提权成功后，第一件事是在/root目录下找flag文件，Breach 1.0的root目录里放着最终的证明文件。读取内容，这就算完整拿下了这台靶机。

拿到flag之后，别忘了清理痕迹。我删掉了/opt/breach/scripts/pwn.sh和/tmp/rootbash，把系统恢复到接近原本的状态。这里提一个建议：刷VulnHub靶机之前，先给虚拟机做一个快照。这样不管是打挂了还是复刷，都能随时回到干净的起点，也方便后续换一条思路重新打一遍。

坦率说，这台机器的提权路径不是那种需要反编译源码、写复杂exp的提权，它考的是细心和完整的信息搜集。只要前面把系统配置全部摸清，提权其实水到渠成。这是我打完Breach 1.0最大的体会。

5. 踩坑记录与实战心得

5.1 常见问题速查表

刷这台靶机的过程里，我遇到过几个实际问题，也看到很多人问类似问题，整理成一张速查表，方便对照排查：

这些问题都不算难，但如果在实战中卡住了，很影响节奏。把常见问题提前想清楚，能省不少排查时间。

5.2 复盘：这套打法还能迁移到哪

最后聊点方法论上的东西。Breach 1.0这套链路——目录爆破发现隐藏入口、备份文件泄露凭据、密码复用横向移动、可写目录叠加定时任务提权——在真实渗透测试中几乎可以原样迁移。尤其是“备份文件在Web目录下可被直接下载”和“普通用户对定时任务依赖目录可写”这两类问题，出现的频率远超想象。

我个人在实际操作中的体会是，每次渗透测试都不要只满足于拿到shell，而是把整个攻击链路的每一步都记录下来：这个入口是怎么发现的？为什么选择了这个字典？哪个响应头或者注释引导了下一步？把这些复盘写下来，比单纯刷十台靶机更涨经验。

Breach 1.0打完之后，我又去刷了同系列的后续版本，发现不少手法是共通的。信息搜集永远是第一步，也是最关键的一步；不要觉得目录爆破无聊，很多时候你离root只差一个多看一眼的注释、一个没设权限的备份文件、一个脆弱的定时任务。这套“慢功夫”打下来，后面再遇到真实目标，你会比大多数人淡定很多。