你的模糊测试方法错了:FFUF与虚拟主机模糊测试

admin 2026-01-14 23:24:47 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文通过实战演练阐述FFUF不仅限于目录扫描,更强调虚拟主机模糊测试的价值。作者在发现目录扫描无效后,利用Host头模糊测试成功定位隐藏资产及Flag,并展示了基于命名模式的组合爆破技巧。核心结论是需转变扫描思维,关注Host头与路由攻击面,以挖掘深层漏洞。 综合评分: 88 文章分类: 渗透测试,WEB安全,安全工具,SRC活动


cover_image

你的模糊测试方法错了:FFUF 与虚拟主机模糊测试

Abhishek Gupta

securitainment

2026年1月14日 13:37 中国香港

我曾经以为 FFuf 不过是另一个 gobuster。

更快?确实。输出更清晰?也许吧。

但说到底,它仍然只是一个目录暴破工具。

这个想法在我接触这个实验室的那一天彻底崩塌了。

HackingHub.io 上最初只是一个简单的练习房间,却在不经意间给我上了一课:当我们把 ffuf 局限在目录扫描时,会错失多少攻击面

这是一个关于虚拟主机模糊测试的故事——四个 flag、隐藏的基础设施,以及一种完全不同的侦察思维方式。

初始设置

这个实验室的标题是 “Virtual Host Basics”

没什么花哨的,也没有吓人的描述,只有四个 flag 在某处等待。起初,这看起来像是一个普通的 ffuf 教程,对我来说就是 vhost 模糊测试,但当我看到那些模式时,我惊呆了。

目标很简单:https://epsilon.ctfio.com/

我在浏览器中打开它。一个静态页面盯着我看。没什么有趣的。于是我做了大多数人都会做的事——打开终端。

舒适区:用 FFUF 进行目录模糊测试

我从一贯的起点开始——目录模糊测试。

ffuf -w wordlist/content.txt -u https://epsilon.ctfio.com/FUZZ

主要的游戏规则改变者 — 字典

看看我这里用的字典。字典永远是游戏规则的改变者。你应该学会如何构建自定义字典。

我使用的字典方法如下:

✅ 使用 seclists 中的常见 web 端点字典

✅ 每当我在任何 medium 博客或社交媒体帖子中看到关键端点时,就把它添加到我的字典里

✅ 然后,当 针对特定目标进行测试时,将其与目标使用的技术栈相关的端点合并

✅ 例如,如果目标使用的是 ReactJS 和 NextJS,那么我会收集与之相关的所有端点并合并到字典中

我在这篇博客中解释了 如何找到 NextJS 和 ReactJS站点上存在的 所有端点。👇👇

https://medium.com/@abhishek-ji/everything-you-need-to-know-about-react2shell-cve-2025-55182-11899c267eb1

好了,让我们继续这个故事。

输出看起来……令人激动。

200。

200。

200。

到处都是 200。

那一刻,感觉像是有进展了。然后现实给了我当头一棒。每个端点都返回相同的响应。

相同的页面。相同的大小。相同的内容。

误报。这是 _大多数人耸耸肩继续前进的时刻_。

但我没有,我盯着输出,问了自己一个问题:

这里到底哪里不一样?

透过噪音看本质。我注意到响应大小。所有请求的响应大小都一样。于是我 过滤了它。

ffuf -w wordlist/content.txt -u https://epsilon.ctfio.com/FUZZ -fs 2275

屏幕安静了下来。这种沉默很有用。现在我知道了一件重要的事:

攻击面不在目录里。

一个小突破改变了一切

我没有放弃,而是换了个方向。子域名

ffuf -w wordlist/subdomain.txt -u https://FUZZ.epsilon.ctfio.com/

这次,ffuf 有了回应。一个子域名打破了沉默:https://app.epsilon.ctfio.com

现在有两个资产了,不是一个。经验告诉我一个很简单的道理:资产越多,错误越多。

这次出现了一个登录页面,我先把它放一边,继续模糊测试,因为这才是主要目标。

仍然没有 Flag,但仍在前进

接下来我尝试了隐藏文件。没什么花哨的,只是扩大覆盖范围。

ffuf -w wordlist/content.txt -u https://epsilon.ctfio.com/FUZZ -e .php,.txt,.html,.json,.yaml,.yml,.lock

什么都没有。没有 flag,没有泄漏。但总感觉哪里不对。我现在有了更多的攻击面,却没有明显的发现。就在那时,我意识到了。我的模糊测试没错,只是 _范围太窄了_。

改变一切的想法:Host 头

⁉️如果真正的应用程序根本不在路径中呢?

⁉️如果它就坐在同一个 IP 后面,等待正确的 Host 头呢?

就在那一刻,我不再思考目录,而是开始思考 路由

用 FFUF 进行虚拟主机模糊测试(转折点)

我构造了第一个虚拟主机模糊测试请求。

ffuf -w dns.txt -u https://epsilon.ctfio.com/ -H "Host: FUZZ"

响应变了。不是状态码,而是内容。不同的页面,不同的行为。就在那一刻,我明白了——这个请求被路由到了完全不同的地方。然后我看到了 第一个 flag

它没有藏在目录里,也没有通过文件暴露。它由一个完全不同的应用程序提供服务,而这个应用程序只有在提供正确的 Host 头时才会响应。

一个没有人想到要锁定的主机名。

[FLAG_ONE]

顺藤摸瓜:测试组合

一个 vhost 从来不会单独存在。我开始测试组合。不同的主机,不同的资产。

ffuf -w dns.txt -u https://epsilon.ctfio.com/ -H "Host: FUZZ"
ffuf -w dns.txt -u https://app.epsilon.ctfio.com/ -H "Host: FUZZ"
ffuf -w dns.txt -u https://epsilon.ctfio.com/ -H "Host: FUZZ.epsilon.ctfio.com"
ffuf -w dns.txt -u https://app.epsilon.ctfio.com/ -H "Host: FUZZ.epsilon.ctfio.com"
ffuf -w dns.txt -u https://epsilon.ctfio.com/ -H "Host: FUZZ.app.epsilon.ctfio.com"
ffuf -w dns.txt -u https://app.epsilon.ctfio.com/ -H "Host: FUZZ.app.epsilon.ctfio.com"

一个接一个,新的虚拟主机出现了。一共四个。

其中一个悄悄地在营销相关的主机中交给了我 第二个 flag

[FLAG_TWO]

开发者送我的礼物

在映射 zeus 主机时,我得到了一些东西:

响应不是错误,而是一条消息。

EvilCorp API Server

For customer data use {host}-zeus.epsilon.ctfio.com

我笑了。然后我会心一笑 😉。然后我又开始模糊测试了。

当模式开始说话

我用好奇心取代了逻辑。

ffuf -w wordlist/dns.txt -u https://epsilon.ctfio.com/ -H "Host: FUZZ-zeus.epsilon.ctfio.com"

这里的经验是什么:

如果你看到像 user-page 这样的端点,那就做 user-FUZZ 和 FUZZ-page,当从这个 fuzz 中找到其他端点时,就无限 fuzz 下去……….

user_page、user~page 或任何对我们来说看起来像模式的东西同样适用。

跟随模式

⁉️如果有 store-zeus,那么也可能有 api-user、admin-page 和 user-profile。

我开始对它们之间带有 的端点进行模糊测试,并发现了一些东西。

于是我用目前为止找到的所有关键词尝试了所有组合。

ffuf -w wordlist/dns.txt -u https://thompson.ctfio.com/ -H "Host: store-FUZZ.thompson.ctfio.com"
ffuf -w wordlist/dns.txt -u https://thompson.ctfio.com/ -H "Host: app-FUZZ.thompson.ctfio.com"
ffuf -w wordlist/dns.txt -u https://thompson.ctfio.com/ -H "Host: FUZZ-app.thompson.ctfio.com"
ffuf -w wordlist/dns.txt -u https://thompson.ctfio.com/ -H "Host: FUZZ-zeus.thompson.ctfio.com"[这个已经做过了]

你猜怎么着,我们是对的,提问总能带来成功!!!!!

curl  https://thompson.ctfio.com/ -H "Host: app-dev.thompson.ctfio.com"
  • 这为我们带来了 flag

[FLAG_THREE]

虚拟主机发现后枚举客户 API

从之前的命令中出现了五个新主机。四个是死胡同,一个不是。

于是我对这个主机上的一些端点或目录进行了模糊测试。果然,就像描述说的那样,Customer API。一个名为 /api的端点出现在屏幕上。

就在那里。最后的 flag。

没有漏洞利用。

没有 payload。

只是正确使用 ffuf 和 host 头模糊测试。

[FLAG_FOUR]

额外提示

  • 你学会了 Vhost 模糊测试,但这并不是 ffuf 的唯一用途。
  • 你还可以用它进行参数模糊测试。
ffuf -w wordlists/params.txt -u https://target.com/user?FUZZ=123

# 尝试用不同的值替换 123
  • 这也不是终点,FFUF 还有更多用例。
  • FFUF 在漏洞赏金中真的很有帮助,因为在进行漏洞赏金侦察时,有时你需要让 Burp 闲下来。

这个实验室教会了我什么

ffuf 不是 gobuster 的替代品,它是一种思维方式的转变。目录只是一个维度。头部、主机和模式才是真正的攻击面隐藏的地方。如果你只模糊测试路径,你就会与敞开的门擦肩而过。

虚拟主机模糊测试是漏洞赏金侦察中最被低估的技术之一,而 ffuf 让它变得极其易于自动化。

这个实验室没有让我觉得聪明,它让我变得 清醒

而这要危险得多。

最让我惊讶的不是那些 flag,

而是在我停止把 ffuf 当作目录扫描器之前,有多少基础设施一直隐藏着。

这种思维方式的转变才是真正能找到漏洞的关键。

祝模糊测试愉快。


You’re Fuzzing All Wrong FFUF & Virtual Host Fuzzing

免责声明:本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:securitainment Abhishek Gupta《你的模糊测试方法错了:FFUF 与虚拟主机模糊测试》

评论:0   参与:  0