戏弄IIS服务器：乐趣与牢狱之灾

# 玩弄IIS服务器：为了乐趣和入狱 来源：https://mll.sh/humiliating-iis-servers-for-fun-and-jail-time 2026年3月18日·阅读时间13分钟 我朋友曾告诉我： > 如果你看到IIS蓝屏，别停在那里；肯定有东西。 他说得对。那个IIS启动页面不是死胡同。在那个蓝色窗口背后，是WWW上配置最混乱的Web服务器之一，它正等着你深入探索。 那么，让我带你看看我在赏金狩猎中如何处理IIS目标： #### 目录 - [嘘，嘘，IIS服务器，你在哪里？](#psst-psst-iis-servers-where-are-you) - [Shodan](#shodan) - [Google Dorking](#google-dorking) - [主动技术指纹识别](#active-tech-fingerprinting) - [好，我找到了一个IIS服务器。然后呢？](#ok-i-found-an-iis-server-now-what) - [内部IP泄露](#internal-ip-disclosure) - [高潮时间](#pwn-time) - [Nuclei模板：自动化枯燥工作](#nuclei-templates-automate-the-boring-stuff) - [那个不是死胡同的HTTPAPI 2.0](#the-httpapi-20-dead-end-that-isnt) - [IIS波浪号枚举：不断馈赠的礼物](#iis-tilde-enumeration-the-gift-that-keeps-giving) - [使用LLM](#using-llms) - [GitHub Dorks解析短文件名](#github-dorks-to-resolve-shortnames) - [使用BigQuery解析短文件名](#using-bigquery-to-resolve-shortnames) - [用Crunch暴力破解剩余部分](#bruteforcing-the-rest-with-crunch) - [模糊测试：IIS专用词表至关重要](#fuzzing-the-iis-specific-wordlist-matters) - [web.config：王国的钥匙](#webconfigthe-keys-to-the-kingdom) - [路径遍历到web.config](#path-traversal-to-webconfig) - [通过无Cookie会话暴露bin目录DLL](#bin-directory-dll-exposure-via-cookieless-sessions) - [反向代理路径混淆](#reverse-proxy-path-confusion) - [通过NTFS技巧绕过认证](#authentication-bypass-via-ntfs-hacks) - [文件上传技巧](#file-upload-tricks) - [通过HPP绕过WAF](#bypassing-wafs-via-hpp) --- ## 嘘，嘘，IIS服务器，你在哪里？ 以下是我用来**寻找**IIS服务器的一些技巧。 ### Shodan 在触碰目标之前，先看看Shodan已经知道了什么： ``` ssl:"target.com" http.title:"IIS" ssl.cert.subject.CN:"target.com" http.title:"IIS" org:"target" http.title:"IIS" ``` 这些示例查询会列出与目标组织或SSL证书关联的IIS机器。有时你会发现无人知晓的临时服务器、被遗忘的管理面板以及内部工具。 随意用其他平台如fofa、censys、netlas、odin等替换或结合Shodan。它们索引的是互联网的不同切片。🍕 ### Google Dorking 在启动扫描器之前，Google就能帮你找到IIS服务器。这些Dorks专门在范围内定位IIS目标： ``` site:target.com intitle:"IIS Windows Server" site:target.com inurl:aspnet_client site:target.com ext:aspx | ext:ashx | ext:asmx site:target.com intext:"Microsoft-IIS" | intext:"X-Powered-By: ASP.NET" site:target.com inurl:_vti_bin site:target.com intitle:"Microsoft Internet Information Services" ``` `aspnet_client`文件夹和`_vti_bin`（FrontPage扩展）是IIS的明显标志；如果Google已经收录了它们，你就有了目标。`ext:aspx`的Dork会捕获所有已索引的ASP.NET页面，这意味着背后是IIS。 此外，通过堆叠通配符来扩大范围，以捕获基本枚举遗漏的嵌套子域名： ``` site:*.target.com intitle:"IIS" site:*.*.target.com intitle:"IIS" ``` 第二个查询不止一次为我发现了开发/临时服务器。 ### 主动技术指纹识别 判断你是否面对IIS的最简单方法是查看响应头。用原始请求探测： ``` nc -v target.com 80 ``` 如果是TLS： ``` openssl s_client -connect target.com:443 ``` 你要找的响应头就像这样： ``` Server: Microsoft-IIS/10.0 X-Powered-By: ASP.NET ``` 但很可能你想**大规模**进行。那么，冷静地使用`httpx`（或`nuclei`）： ``` httpx -l targets.txt -td | grep IIS | tee iis-targets.txt ``` ## 好，我找到了一个IIS服务器。然后呢？ 首先，确认我们面对的是什么，并尽可能多地获取服务器愿意免费给出的信息。 ### 内部IP泄露 这是一个大多数人都错过的免费信息。向某些IIS配置（尤其是Exchange或OWA前端）发送HTTP/1.0请求，服务器有时会在`Location`头中透露一个内部IP： ``` curl -v --http1.0 http://example.com ``` 你可能会得到类似这样的响应： ``` HTTP/1.1 302 Moved Temporarily Location: https://192.168.5.237/owa/ Server: Microsoft-IIS/10.0 X-FEServer: NHEXCHANGE2016 ``` 那个内部IP和`X-FEServer`头直接告诉了你Exchange服务器的内部主机名。记下它。这是信息泄露，可以在后续步骤中利用。 ## 高潮时间 侦察到此为止，让我们进入正题。 ### Nuclei模板：自动化枯燥工作 一旦你获得了IIS目标列表，用相关的标签批量使用nuclei： ``` nuclei -l iis-targets.txt \ -tags microsoft,windows,asp,aspx,iis,azure,config,exposure -silent ``` 我喜欢在手动侦察的同时在后台运行这个。 ### 那个不是死胡同的HTTPAPI 2.0 你会遇到很多IIS服务器，它们只返回一个通用的`HTTPAPI 2.0 404`错误。大多数人看到这个以为“这里什么都没有”。错。 这实际上意味着服务器在`Host`头中没有收到正确的域名。IIS实例就在那里，它运行着某个东西，但绑定到了特定的虚拟主机。你需要找出是哪个。 两种方法： 1. 检查SSL证书。subject或SAN字段通常包含你需要的主机名。只需在浏览器中打开并检查证书。 2. 如果证书无用，则暴力枚举虚拟主机。像`ffuf`配合`Host`头词表这样的工具在这里很好用： ``` ffuf -u https://TARGET_IP/ -H "Host: FUZZ.target.com" -w vhosts.txt -fs 0 ``` 当找到正确的主机名时，服务器突然苏醒，为你提供真正的应用程序，而不是无用的404。 ### IIS波浪号枚举：不断馈赠的礼物 这是最被低估的技术之一。IIS继承了旧DOS 8.3文件名约定的遗留行为。通过发送精心构造的请求，即使禁用了目录列表，你也可以枚举服务器上文件和目录的短名称。 你需要的工具是shortscan（https://github.com/bitquark/shortscan）： ``` shortscan https://target.com/ -F -p 1 ``` 注意`-F -p 1`参数告诉shortscan模糊测试目录（完整URL）并枚举短名称（`-p`代表*patience*）。 另一个可用的工具是burp的IIS Tilde Enumeration Scanner（https://portswigger.net/bappstore/523ae48da61745aaa520ef689e75033b）。 这会输出短名称片段，比如： ``` File: WEB~1.CON File: GLOBAL~1.ASA File: SITEBA~1.ZIP Dir: ADMIN~1 ``` 现在关键在于：`WEB~1.CON`显然是`web.config`。但`SITEBA~1.ZIP`是什么？是`sitebackup.zip`？`sitebase.zip`？`sitebatch.zip`？如果我们能猜出完整名称，就可以尝试下载它。 让我们探讨一些生成词表的方法： #### 使用LLM 类似这样： ``` 只返回一个单词列表，用换行分隔，不返回其他内容。确保单词只包含字母数字字符。 根据这个片段，列出猜测剩余部分单词的所有可能，确保片段是你猜测的子字符串。 尽可能广泛地列出。 片段：{shortname} ``` #### GitHub Dorks解析短文件名 GitHub的代码搜索基本上是一个免费的数据库。数以百万计的仓库意味着数以百万计的真实文件名，你可以根据你的短名称片段进行模式匹配。比盲目猜测有效得多。 思路：从你的短名称中取前6个字符（`~1`之前的所有内容），然后在GitHub上搜索以这些字符开头且以正确扩展名结尾的文件名。 直接在GitHub的代码搜索界面中使用： ``` # 在GitHub搜索栏，选择"Code"并使用path:过滤器 path:/.ds_st path:/global*.asa path:/connec*.config ``` 为了半自动化，试试GSNW（https://github.com/retkoussa/gsnw）（GitHub Short Name Wordlist）。你提供短名称片段，它会抓取GitHub代码搜索中匹配的文件名： ``` python gsnw.py "siteba" output.txt ``` 还有另一个工具GitHub-IIS-Shortname-Generator（https://github.com/m0rd3caii/GitHub-IIS-Shortname-Generator），做同样的事情，输出一个干净的词表： ``` python scanner.py WEBDEV ``` ``` 找到的匹配项： -------------------------------------------------- - WebDev.md - WebDeveloper.java - webdev.txt - webdevicons.lua -------------------------------------------------- 总共唯一匹配：86 ``` 另一个很酷的选择是shortnameguesser（https://github.com/projectmonke/shortnameguesser），它接收短名称扫描器的输出，并通过查询多个来源来生成针对性词表，以解析片段。 #### 使用BigQuery解析短文件名 这里变得有趣了。这个技巧灵感来自Assetnote关于使用BigQuery在IIS上发现隐藏文件的研究（https://www.assetnote.io/resources/research/finding-hidden-files-and-folders-on-iis-using-bigquery）。思路很简单：使用Google BigQuery的公开GitHub数据集搜索整个GitHub代码库，查找与你的短名称模式匹配的文件名。 如果你的短名称扫描返回`SITEBA~1.ZIP`，在BigQuery中运行： ```sql SELECT DISTINCT path FROM `bigquery-public-data.github_repos.files` WHERE REGEXP_CONTAINS(path, r'(?i)(\/siteba[a-z0-9]+\.zip|^siteba[a-z0-9]+\.zip)') LIMIT 1000 ``` 你会得到真实项目中的真实文件名：`sitebackup.zip`、`sitebase.zip`等等。现在你有了一个聚焦的词表，而不是盲目猜测。 #### 用Crunch暴力破解剩余部分 当LLM、GitHub和BigQuery都无果时，有时你只能简单粗暴地暴力破解剩余字符。`crunch`可以为给定的字符长度生成所有可能组合的词表： ``` crunch 4 6 abcdefghijklmnopqrstuvwxyz -o wordlist.txt ``` 这会生成所有4到6个字符的小写字母字符串。由于8.3短名称显示前6个字符，你通常只需要猜测剩余部分。 假设shortscan给了你`DESKTO~1.ZIP`。你知道文件名以`deskto`开头并以`.zip`结尾。现在需要找出`deskto`后面是什么。文件可能是`desktop.zip`、`desktopbackup.zip`、`desktop-files.zip`等。 使用ffuf配合基于模式的模糊测试来覆盖各种变化： ``` ffuf -w wordlist.txt -u https://target.com/desktoFUZZ.zip -mc 200,301,302,403 ffuf -w wordlist.txt -u https://target.com/desktop-FUZZ.zip -mc 200,301,302,403 ffuf -w wordlist.txt -u https://target.com/desktop_FUZZ.zip -mc 200,301,302,403 ffuf -w wordlist.txt -u https://target.com/desktop%20FUZZ.zip -mc 200,301,302,403 ffuf -w wordlist.txt -u https://target.com/desktopFUZZ.zip -mc 200,301,302,403 ``` 注意不同的分隔符：连字符、下划线、URL编码的空格，以及没有分隔符。开发人员在命名约定上并不一致，所以你需要覆盖所有模式。`%20`变体捕捉了有人用空格命名文件的常见情况——Windows不在意，IIS也会正常提供。 这是在智能方法失败时的暴力后备方案，老实说，它比你想的更容易奏效。 ### 模糊测试：IIS专用词表至关重要 通用词表对通用服务器来说不错。但IIS不是通用的。你需要模糊测试只存在于IIS/.NET生态系统中的东西。这些是高价值目标： ``` /web.config /web.config.bak /web.config.old /web.config.txt /global.asax /trace.axd /elmah.axd /connectionstrings.config /appsettings.json /appsettings.Development.json /appsettings.Staging.json /appsettings.Production.json /appsettings.Local.json /secrets.json /WS_FTP.LOG /_vti_pvt/service.cnf ``` 例如，`trace.axd`是ASP.NET跟踪查看器。如果启用，你会得到完整的请求/响应日志，包括头、cookie，有时还有凭据。`elmah.axd`是错误日志查看器；同样的情况。这些基本上是开发人员忘记关闭的调试端点。🫣 并且始终使用IIS特定的扩展名进行模糊测试： ``` .asp,.aspx,.ashx,.asmx,.wsdl,.wadl,.config,.xml,.zip,.txt,.dll,.json ``` 一个实用的ffuf命令： ``` ffuf -u https://target.com/FUZZ -w iis-wordlist.txt \ -e .asp,.aspx,.ashx,.asmx,.config,.json,.xml,.zip,.bak,.txt \ -mc 200,301,302,403 -fs 0 ``` 我喜欢的一些IIS专用词表： - secLists IIS.txt（https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/IIS.txt）：经典。涵盖默认IIS路径、常见处理程序和遗留文件。使用它时不需要添加扩展名，因为条目已经包含。 - orwa的iis.txt（https://github.com/orwagodfather/WordList/blob/main/iis.txt）：由Godfather Orwa策划（就是下面参考资料中"THE POWER OF RECON"演讲的那位）。经过真实赏金计划的实战检验。这是我首先使用的词表。👑 - orwa的aspx.txt（https://github.com/orwagodfather/WordList/blob/main/aspx.txt）：上述词表的伴侣，专注于.aspx端点。 - wfuzz iis.txt（https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt）：虽小但专注于已知脆弱的IIS路径。 - dirbuster-ng iis.txt（https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt）：另一个紧凑的词表，针对IIS特定的弱点。 - Assetnote词表（https://wordlists.assetnote.io/）：从真实爬虫数据自动生成，每月更新。获取ASP和ASPX词表。这些词表来自实际生产应用，因此命中率显著优于通用列表。 - OneListForAll（https://github.com/six2dez/OneListForAll）："Web模糊测试的rockyou"。针对性的运行使用`onelistforallshort.txt`，完整列表整夜运行。 专业提示：IIS不区分大小写。如果你的词表混合大小写，你是在浪费请求做重复工作。使用小写的词表，如SecLists的`raft-medium-words-lowercase.txt`，或者通过`tr '[:upper:]' '[:lower:]' | sort -u`管道处理自定义列表，然后再喂给ffuf。 ### web.config：王国的钥匙 如果你能通过路径遍历、配置错误的备份文件或短名称辅助发现读取`web.config`，你