羞辱IIS服务器：有趣但可能面临牢狱之灾
一位朋友曾告诉我：
如果你看到IIS的蓝色屏幕，不要停在那里；背后一定有什么东西。
没错，他说得对。那个IIS启动页面并不是死胡同。在那扇蓝色窗口背后，是互联网上配置最混乱的Web服务器之一，它正等着你去深入探索。
那么，让我带你看看我在漏洞赏金中如何对付IIS目标：
嘘，IIS服务器，你在哪里？
以下是我用来发现IIS服务器的一些技巧。
在接触目标之前，先去查查Shodan已经知道的信息：
这些示例查询会列出与目标组织或SSL证书关联的IIS服务器。你有时会发现一些暂存服务器、被遗忘的管理面板，以及没人意识到暴露在互联网上的内部工具。
你可以随意用fofa、censys、netlas、odin等其他平台替换或结合Shodan使用。它们索引的是互联网的不同切片。
在你启动扫描器之前，Google就能帮你找到IIS服务器。这些Google dork专门用于在范围内定位IIS目标：
aspnet_client文件夹和_vti_bin（FrontPage扩展）是IIS的明显标志；如果Google已经索引了它们，你就找到了目标。ext:aspx dork会捕获任何被索引的ASP.NET页面，这意味着底层是IIS。
另外，使用堆叠通配符来扩展你的范围，以捕获基本枚举遗漏的嵌套子域名：
第二个技巧曾多次帮我发现开发/暂存服务器。
判断你是否面对IIS的最简单方法是查看响应头。发送一个原始请求：
你在响应头中要找的是这样的内容：
但你可能想大规模进行。那就保持冷静，使用httpx（或nuclei）：
好的，我找到了一个IIS服务器。接下来呢？
首先，确认我们面对的是什么，并尽可能多地获取服务器愿意免费提供的信息。
这里有一个大多数人忽略的免费信息。向某些IIS配置（尤其是Exchange或OWA前端）发送HTTP/1.0请求，服务器有时会在Location头中返回一个内部IP：
你可能会得到类似这样的响应：
那个内部IP和X-FEServer头告诉你Exchange服务器的内部主机名。记下它。这是信息泄露，我们可以在后续步骤中利用。
攻击时间
侦察够了，让我们进入正题。
一旦你有了IIS目标列表，用nuclei配合相关标签进行扫描：
我喜欢在手动侦察的同时在后台运行这个。
你会遇到很多IIS服务器返回通用的HTTPAPI 2.0 404错误。大多数人看到这个会认为“这里什么都没有”。错。
这实际上意味着服务器在Host头中没有收到正确的域名。IIS实例是存在的，它在运行某些东西，但绑定到了特定的虚拟主机。你需要找出是哪一个。
如果证书没有帮助，就暴力破解虚拟主机。像ffuf配合Host头字典这样的工具在这里很有效：
当你找到正确的主机名时，服务器会突然“醒来”，为你提供一个真正的应用程序，而不是那个无用的404。
这是最被低估的技巧之一。IIS有一个从旧DOS 8.3文件名约定继承而来的遗留行为。通过发送特制的请求，你可以枚举服务器上文件和目录的短名称，即使目录列表被禁用。
你需要的工具是shortscan：
注意-F -p 1参数告诉shortscan模糊测试目录（完整URL）并枚举短名称（-p代表耐心）。
另一个你可以使用的工具是Burp的IIS Tilde Enumeration Scanner。
这会输出像这样的短名称片段：
现在问题是：WEB~1.CON显然是web.config。但SITEBA~1.ZIP是什么？是sitebackup.zip？sitebase.zip？sitebatch.zip？如果我们能猜出完整名称，就可以尝试下载它。
让我们探索一些生成字典的选项：
GitHub的代码搜索基本上是一个免费的文件名数据库。数百万个仓库意味着数百万个真实世界的文件名，你可以根据短名称片段进行模式匹配。这比盲目猜测有效得多。
思路：从短名称中取前6个字符（~1之前的所有内容），然后在GitHub上搜索以这些字符开头并以正确扩展名结尾的文件名。
直接使用GitHub的代码搜索UI：
要半自动化这个过程，可以试试GSNW（GitHub Short Name Wordlist）。你输入短名称片段，它会从GitHub代码搜索中抓取匹配的文件名：
还有GitHub-IIS-Shortname-Generator，它做同样的事情并输出一个干净的字典：
另一个很酷的选择是shortnameguesser，它接收短名称扫描器的输出，并通过查询多个来源来解析片段，生成有针对性的字典。
这就是事情变得有趣的地方。这个技巧灵感来自Assetnote关于使用BigQuery在IIS上发现隐藏文件的研究。思路很简单：使用Google BigQuery的公共GitHub数据集，在整个GitHub代码库中搜索匹配你短名称模式的文件名。
如果你的短名称扫描返回了SITEBA~1.ZIP，在BigQuery中运行这个：
你会从真实项目中得到真实文件名：sitebackup.zip、sitebase.zip等等。现在你有了一个有针对性的字典，而不是盲目猜测。
当LLM、GitHub和BigQuery都无果时，有时你只需要回归原始，暴力破解剩余字符。crunch可以为给定字符长度生成所有可能组合的字典：
这会生成长度从4到6个字符的所有小写字母字符串。由于8.3短名称显示前6个字符，你通常只需要猜测剩余部分。
假设shortscan给了你DESKTO~1.ZIP。你知道文件名以deskto开头，以.zip结尾。现在你需要弄清楚deskto后面是什么。文件可能是desktop.zip、desktopbackup.zip、desktop-files.zip等。使用ffuf进行基于模式的模糊测试来覆盖各种变体：
注意不同的分隔符：连字符、下划线、URL编码的空格，以及没有分隔符。开发人员的命名约定不一致，所以你想覆盖所有模式。%20变体捕获了令人惊讶的常见情况：有人用空格命名文件——Windows不在乎，IIS也会正常提供。
这是当智能方法失败时的暴力破解后备方案，老实说，它比你预期的更有效。
通用字典适用于通用服务器。IIS不是通用的。你需要模糊测试只存在于IIS/.NET生态系统中的东西。
这些是需要模糊测试的高价值目标：
例如，trace.axd是ASP.NET跟踪查看器。如果启用了它，你会得到完整的请求/响应日志，包括头信息、cookie，有时还有凭据。elmah.axd是错误日志查看器；同样的情况。这些基本上是开发人员忘记关闭的调试端点。
并且始终使用IIS特定的扩展名进行模糊测试：
一个实用的ffuf命令：
一些我喜欢的IIS特定字典：
IIS不区分大小写。如果你的字典混合大小写，你会在重复请求上浪费资源。使用小写字典，比如SecLists的raft-medium-words-lowercase.txt，或者通过tr '[:upper:]' '[:lower:]' | sort -u管道处理你的自定义列表，然后再输入到ffuf。
如果你能通过路径遍历、配置错误的备份文件或短名称辅助发现来读取web.config，你基本上已经赢得了整个任务。
原因如下：IIS的web.config文件通常包含机器密钥。这些是用于签名和加密ViewState的加密密钥。如果你有机器密钥，你可以伪造恶意的序列化ViewState负载，并通过反序列化实现远程代码执行。
这是现存最可靠的IIS RCE链之一。一旦你有了密钥，像ysoserial.net这样的工具会为你生成负载。
如果你发现任何类型的文件下载或文件读取参数，尝试类似这样的东西：
即使没有路径遍历，也有一种巧妙的方法直接从bin目录中提取DLL。ASP.NET的遗留无cookie会话功能允许你使用(S(X))语法将会话令牌直接嵌入URL路径中。美妙之处在于：你可以滥用这一点来混淆IIS的路径解析，并访问bin文件夹，即使它本应被阻止。
那个URL看起来像乱码，但IIS将(S(X))段解释为无cookie会话令牌，在路径规范化期间剥离它们，最终将路径解析为/bin/Newtonsoft.Json.dll。
现在，Newtonsoft.Json.dll是一个默认库，本身不会包含应用程序机密。但该技术适用于bin目录中的任何DLL。如果你已经通过波浪号短名称或其他方法枚举了文件名，就替换成实际的应用程序DLL：
下载这些DLL，放入JetBrains dotPeek或dnSpy中，你就能读取完整的反编译源代码：硬编码的凭据、API密钥、内部端点逻辑、自定义认证实现——所有开发人员认为已安全编译的内容。
当IIS位于反向代理后面（或充当反向代理）时，你有时可以利用路径规范化差异来访问本不应访问的路径。
经典技巧：如果/admin/返回403或重定向，尝试：
代理看到/anything/..%2fadmin/，认为你在请求/anything/。它转发请求。但IIS将%2f解码为/，解析路径遍历，并提供/admin/。你刚刚绕过了访问控制。
IIS 7.5及类似版本对NTFS备用数据流和索引分配有一个有趣的行为。你有时可以通过类似这样的路径绕过基本认证：
这些利用了IIS解析NTFS元数据流的方式。认证模块看到一个它不认为是受保护的路径，但文件系统仍然将其解析为实际目录。
如果你在IIS目标上找到上传功能，开发人员几乎肯定屏蔽了.aspx和.asp。但IIS默认提供大量扩展名作为text/html，这意味着通过文件上传实现存储型XSS。
渲染为HTML的扩展名（基本XSS向量有效）：
支持基于XML的XSS向量的扩展名：
IIS在文件名中的尾随点有一个怪癖。如果上传过滤器阻止了shell.aspx，尝试：
IIS会剥离尾随点并正常提供文件。这个绕过技巧已经存在多年，人们仍然没有过滤它。
对于服务器端包含，这些扩展名值得尝试：
通过HPP绕过WAF
最后一个技巧。如果IIS目标前面有WAF阻止你的负载，HTTP参数污染（HPP）有时可以将你的负载分散到重复的参数中：
IIS和ASP.NET默认用逗号连接重复的参数值，这可以在WAF的另一侧重新组装你的负载。
总结
正如我们所见，IIS在漏洞赏金中的攻击面相当广泛，但一直测试不足。每个人都在追逐最新的JS框架漏洞，而这些Windows服务器却坐在那里，泄露内部IP、提供自己的配置文件，并且短名称枚举完全开放。
所以，不要跳过蓝色屏幕。更努力地侦察。
进一步阅读
在准备这篇文章的过程中，我收集了一些很棒的参考资料：
原文出处：https://mll.sh/humiliating-iis-servers-for-fun-and-jail-time
