文章总结： 本文讲述了一名安全研究人员如何从看似无害的默认IIS页面开始，通过目录扫描发现隐藏网站，进而找到敏感的build.xml文件，最终利用文件中暴露的内部端点信息发现严重SQL注入漏洞。文章强调了坚持探索、黑客社区价值以及如何将看似无害的信息泄露与实际漏洞联系起来，展示了安全测试中不应忽视任何细节的重要性。
综合评分： 89
文章分类： 渗透测试,漏洞分析,WEB安全,实战经验,应急响应
从默认 IIS 页面到关键 SQL 注入
hai dragon
安全狗的自我修养
2025年12月11日 15:13
湖南
官网：http://securitytech.cc/
#
为什么“无聊”的基础设施常常藏着最危险的秘密
The Setup：又是平常的一天，又是新的项目
这只是 HackerOne 私有项目中的普通一天。像所有老练的猎人一样，我先做信息收集，用 Subfinder（启用所有 API key）扫描子域。接着跑 httpx-toolkit 查存活主机，我得到了平时的目标列表。
之前我已经给这家公司报过两次 SQL 注入 了。
改变一切的“无聊”发现
在猎过三个子域后，我回到列表继续找可能比较有趣的点。我查看之前的截图，其中有两个子域显示的是 默认 IIS 页面。
按 Enter 或点击查看完整图片
示例默认 IIS 页面
多数猎人看到这种就直接跳过了。默认页面？无聊。
但我想起了一篇 writeup 里的话：
“没有人会花钱托管空白或默认页面。”
向那位写下这句话的黑客致敬——他们的话在我脑中回响，我决定深入看看。
第一步：短文件名扫描，以及完全失败的开始
在 fuzz 之前，我先跑了一个 IIS short name scanner。结果：存在漏洞。我从兴奋变成困惑——我知道它有漏洞，但不知道怎么利用。
我开始用各种字典进行 fuzz。
几个小时过去了——毫无结果。
沮丧之下，我在 X（原 Twitter）发了条简单的帖子：
“Now what”，并附上扫描截图。
按 Enter 或点击查看完整图片
一个猎人回复：“试试 GitHub 上 @orwagodfather 的字典。”
我想：也行吧。于是跑：
ffuf -u "https://target.com/FUZZ" -ac -fs 0 \
-w <(curl -s "https://raw.githubusercontent.com/orwagodfather/WordList/refs/heads/main/iis.txt")
五分钟后：200 OK。
不仅是 200，而且 响应长度略微变大。
点进去，“无聊”的 IIS 页面变成了一个隐藏在默认页面后的小网站。
游戏正式开始了。🔥
点击所有内容，但什么都没发现
我点了每个链接、按钮、功能——毫无发现。看起来很安全。
这时我想起我最喜欢的一位猎人的演讲——关于如何攻破 IIS。我重新打开他的幻灯片，其中关键一句话：
“如果 fuzz 失败，试试这些扩展：xml, zip, txt, json, js, obj, asmx, xsl, dll…”
例如：
ffuf -u "https://target.com/FUZZ.ext" -w wordlist.txt -ac -fs 0
但 FFUF 的 extension fuzz 对我不太正常——只测一个扩展就停……不知道为什么 🤷♂️
于是我写了一个快速的 bash 脚本来 brute force 扩展：
#!/bin/bash
Default_WORDLIST="/usr/share/seclists/Discovery/Web-Content/big.txt"
EXTENSIONS="xml dll svc zip 7z htm html json js aspx asmx ashx debug"
...
结果令人震惊：扫描到了
inspection.aspxresearch.aspx（SOAP API）- 最重要的：
build.xml
黄金文件：build.xml
打开 build.xml 就像发现藏宝图，它暴露了：
- 内部敏感 endpoint
- DLL 文件
- 隐藏 API
- 基础设施细节
片段示例：
<sources>
<includename=".\*.cs"/>
<includename=".\Admin\*.aspx.cs"/>
<includename=".\Admin\*.cs"/>
<includename=".\test\*.aspx.cs"/>
</sources>
这是典型的信息泄露，但我知道如果直接上报——十有八九是 informative（低危）。
我需要“影响力”。
追逐开始
从文件分析到的一堆 endpoint，我依次测试。
其中 /test 会重定向到 AWS 测试页——没用 😒
所有的 endpoint 都试遍——还是没有。
沮丧，我关上笔记本休息。😣
黑客的困境：什么时候该放弃？
第二天，我准备换一个子域。
但心里那句直觉在提醒我：
“再试一次，只要一次。”
我反驳自己：
“所有都看过了，浪费时间。”
但那个声音仍然存在。
我勉强打开 Burp，翻 HTTP 历史。
突然，我看到一个奇怪的请求 —— 有 5 个参数，之前漏掉了。
其中一个参数叫：group
我脑海闪过一个念头：
“这东西是不是进数据库？”
我随手注入一个 '
页面崩了，报数据库错误。
按 Enter 或点击查看完整图片
😎 基于报错的 SQL 注入
确认与利用
时间盲注 payload 一试——有效。
这是真·SQL 注入。
我用 Ghauri（比 sqlmap 强一点，尤其 XOR payload）成功拿到数据库数据。
信息泄露报告被嫌弃？没关系
休息时我想：“不如把 build.xml 信息泄露也报上去吧？”
报了。
果然：Informative（P5）。
审阅者问：
“你怎么证明可以访问这些 DLL 文件和敏感数据？”
我试了——做不到。
但转机来了：
在 SQL 注入报告里我备注：
“你们关闭了
build.xml报告，但我就是根据它找到这个 严重 SQL 注入 的。”
第二天：
信息泄露报告被重新打开并确认有效。
SQL 注入则单独 triage。
按 Enter 或点击查看完整图片
关键经验
- 默认页面并不无聊
——它们通常无人维护，漏洞最多。 - 黑客社区很重要
——X 上那条回复改变了整个猎杀过程。 - 坚持比天赋更重要
——最后的那一次尝试常常就是关键突破。 - 记录一切
——HTTP 历史救了这次行动。 - 关联多个弱点，能形成重大漏洞链
——信息泄露 + 业务端点 = SQL 注入。
黑客的思维方式
当直觉告诉你“再试一次”时，请听它的。
最后一试、最后一页、最后一个参数——往往金矿就在那。
每个人忽略的基础设施、
无聊的 IIS 页面、
“不可利用”的信息泄露……
组合起来却能导致一次重大数据库泄露。
- 公众号:安全狗的自我修养
- vx:2207344074
- http://gitee.com/haidragon
- http://github.com/haidragon
- bilibili:haidragonx
#
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全狗的自我修养 hai dragon《从默认 IIS 页面到关键 SQL 注入》