在近期一次网站渗透测试中，我发现一个非常容易遭受CVE-2020-1147危害的SharePoint案例。我被规定在没有运作一切指令的情形下搭建Web Shell，以防止一切很有可能布署在服务器上的EDR解决方法。因为总体目标SharePoint网络服务器以较小的权利在IUSR客户下运作，因而我们不能简易地根据运用反序列化系统漏洞（CVE-2020-1147）在Web文件目录中建立Web Shell。我还记得之前在运作PowerShell命令时，进攻非常容易被发觉，因此必须更隐秘的方式！
这篇文章表明了在我们存有执行命令系统漏洞但Web文件目录不能写时怎样建立Web Shell，从理论上讲，大家应当可以实行此实际操作，由于大家的编码已经Web程序中实行，因而我觉得出了下列俩种解决方法：
应用C＃建立作用全方位的Web Shell
虽然我非常喜爱应用Web Shell，可是大部分功能齐全的.NET全是HTML和C＃编码的结合物。因而，清除他们以将其做为纯C＃程序执行十分艰难且用时。我的解决办法是应用aspnet_compiler指令，便于从其临时性编译程序文档中获得ASPX Web Shell的C＃编码。
另一个问题是，在我们想与内嵌式Web Shell开展互动时，当易受攻击的网页页面和Web Shell期待彻底不一样的HTTP要求时，大家也许必须运用大家的易受攻击的作用，这也许会造成矛盾或压根不适合。因而，URL和文章正文中全部与Web Shell有关的主要参数及其HTTP形容词，內容种类，Cookie和其它自定标头都要以某类方法封装形式，便于在运用执行命令以后在服务端再次建立。虽然自定JavaScript编码很有可能可以解决一些封装形式每日任务，可是捕获HTTP要求的全部必不可少层面也许并不易。因而，应用代理商解决要求好像是一种更强，更简单的方式。例如，可以根据撰写Burp Suite扩展程序来进行此实际操作，该扩展程序可以捕获对Web Shell的全部要求，这种要求最开始是利用运用执行命令问题载入的。此拓展可以将Web Shell主要参数封装形式在HTTP要求的标头中，推送该HTTP要求以运用执行命令问题。应用标头很有可能会受限制，尤其是当Web Shell要求包括比较大的主要参数（例如已经文件上传时）时。可是，应用代理商更换字符串数组可以确保可以在服务端再次建立含有适度主要参数（例如HTTP文章正文、內容种类、HTTP形容词和URL主要参数）的预估HTTP要求，以便Web Shell一切正常工作中。应当特别注意的是，使HTTP要求中的审阅主要参数（例如表格主要参数）可应用反射面载入是非常非常容易的。另一件必须留意的关键一件事是消除一切很有可能在运作web shell编码以前建立的HTTP回应，响应还要在web shell实行后完毕，以避免一切出现意外数据信息影响来自web shell的预估回应。
虽然这类技术性看上去行得通，但我还是沒有应用它，因为它很繁杂，并且每一次实际操作都要向服务器发送很多web要求，以降低潜在性的检验风险性。
根据乱用.NET中的虚似途径给予程序流程来建立虚似文档（ghost文件）
应用.NET，可以界定虚拟途径，便于为文件系统软件之外的别的储存源给予虚拟文件。此作用十分强劲，因为它乃至可以用以替换并未缓存文件或编译程序的目前文件。这代表根据替换目前的.NET文件（例如.aspx，.svc，.ashx，.asmx等）来表明网络攻击的预估內容，即使针对钓鱼攻击或其他软件进攻还可以派上用场。 SharePoint自身应用相似的办法来建立ghost页面和未代管的页面！
该解决方法对测试工程师来讲具备最少的多元性，由于可以将Web Shell立即置入原始漏洞检测编码中。 YSoSerial.Net新项目中的GhostWebShell.cs文件表明了大家建立的用以在易受攻击的Web应用软件上运作Web Shell的编码。
为了更好地应用此编码，可以对Web Shell文件的具体内容开展base-64编号并将其储存在webshellContentsBase64主要参数中。 webshellType参数包括Web Shell拓展，而targetVirtualPath主要参数包括将在云服务器上建立的虚拟途径。除开这种主要参数外，别的主要参数可以不变，假如必须越来越多的自定，编码中的注解就充足了。
下列指令表明了怎么使用它来应用YSoSerial.Net转化成LosFormatter有效载荷的实例：
.\ysoserial.exe-gActivitySurrogateSelectorFromFile-fLosFormatter-c"C:\CoolTools\ysoserial.net\ExploitClass\GhostWebShell.cs;System.dll;System.Web.dll;System.Data.dll;System.Xml.dll;System.Runtime.Extensions.dll"
应当特别注意的是，在应用ActivitySurrogateSelectorFromFile gadget以前，应当应用ActivitySurrogateDisableTypeCheckgadget，便于为最新版本的.NET Framework开启它。
下列流程表明怎么使用此技术性在易受CVE-2020-1147进攻的SharePoint网络服务器上建立虚拟Web Shell：
1.提前准备基本上有效载荷，在其中包括运用远程控制执行命令系统漏洞需要的DataSet有效载荷：
POST/_layouts/15/quicklinks.aspx?Mode=SuggestionHTTP/1.1uthorization:[ntlmauthheader]Content-Type:application/x-www-form-urlencodedHost:[target]Content-Length:[lengthofbody]._VIEWSTATE=&__SUGGESTIONSCACHE._=[DataSetpayloadfromYSoSerial.Net]
2.转化成并传送数据集有效载荷以禁止使用ActivitySurrogateSelector的.NET Framework v4.8 种类维护：
.\ysoserial.exe-pSharePoint
3.转化成并传送数据集有效载荷以运作虚拟Web Shell：
.\ysoserial.exe-pSharePoint
可以变更GhostWebShell.cs文件，使其更具有自定性，以给予好几个文档及其掩藏本身，直到见到独特的标头或文件夹名称才行。当并未编译程序目前文件目录中的特殊文档时，变更IsPathVirtual函数公式也很便捷。现阶段，它会回应全部传到的要求，可是你也许期待将其限定为一些名字，或是查验文件扩展名以给予不一样的內容。
绕开Microsoft.AspNet.FriendlyUrls
从.NET 4.5逐渐，Web应用软件可以应用友善的URL在偏向ASPX网页页面时不应用URL中的“.aspx”，这可以阻拦大家建立ghost web shell的方式。下边的解决方法可以为应用此作用的Web应用软件遮盖此设定。
foreach(varrouteinSystem.Web.Routing.RouteTable.Routes){if(route.GetType().FullName=="Microsoft.AspNet.FriendlyUrls.FriendlyUrlRoute"){varFriendlySetting=route.GetType().GetProperty("Settings",System.Reflection.BindingFlags.Instance|System.Reflection.BindingFlags.Public);varsettings=newMicrosoft.AspNet.FriendlyUrls.FriendlyUrlSettings();settings.AutoRedirectMode=Microsoft.AspNet.FriendlyUrls.RedirectMode.Off;FriendlySetting.SetValue(route,settings);}}
该编码已包括在GhostWebShell.cs文件中，必须时，该注解不用撤销注解（建立有效载荷也必须Microsoft.AspNet.FriendlyUrls.dll文档）。
绕开预编译的限定
当应用软件处在预编译方式时，.NET中的虚似途径给予程序流程没法申请注册。可是，因为大家早已可以在应用软件上实行编码，因而可以应用反射面变更System.Web.Compilation.BuildManager.IsPrecompiledApp特性。该编码已包括在YSoSerial.Net新项目的GhostWebShell.cs文件中。
結果，即使应用软件处在预编译方式，还可以建立虚似Web Shell。
运用别的Web程序处理
当运用执行命令系统漏洞时，虚似文档方式将起功效，该执行命令系统漏洞应用另一个Web程序处理，例如用以Web服务的程序处理。虽然它们的回应很有可能不可能表明虚似Web Shell的实行，可是依然可以根据同时在网页中访问到虚似Web Shell来浏览它。
虚似文档检验体制
虽然虚似文档仅出现于存储空间中，可是两者的编译程序版本号储存在临时性部位中，该临时性部位用以.NET页的编译程序，默认设置文件目录通常采取下列文件格式：
C:\Windows\Microsoft.NET\Framework64|Framework\v[version]\TemporaryASP.NETFiles\[appname]\[hash]\[hash]\
因而，根据检验创好的缓存文件，有可能检验到故意编译程序文档。应当特别注意的是，在应用软件的默认设置文件目录中接手未编译程序的. net文件是很有可能的。因而，除非是应用软件处在预编译方式，不然检验创好的文件夹名称不可以作为检测服务体制，因而，不可建立新的已编译程序文档。
假如你不用在系统文件上建立一切文档，则可以考量将文中中探讨的第一个解决方法（在C＃中建立可常规运转的Web Shell）做为代替计划方案。可是，此解决方法具备根据检验未数据加密的总流量以获得特殊签字或探测到从特殊由来向既定总体目标传出的非常大的Web要求的检验风险性。
文中翻譯自：https://www.mdsec.co.uk/2020/10/covert-web-shells-in-net-with-read-only-web-paths/倘若转截，请标明全文详细地址。