proxynotshell - 微软交易所中声称的零天的故事
昨天，网络安全供应商GTSC网络安全删除了一个博客，称他们已经发现了对新的Microsoft Exchange Zero Day的开发：
警告：新的攻击活动利用了Microsoft Exchange Server上的新0天RCE漏洞|博客|GTSC -CUNGCấPCácdịChvụbảoMậTtoàndiện（gteltsc.vn）
如果零一天是真实的，历史已经显示了事物迅速向南走…所以让我们深入研究。
您可以看到ZDI确认他们在这里接受了ZDI-CAN-18333和ZDI-18802
我从GTSC写的有些问题，例如：
该请求字符串看起来完全像Proxyshell，这是2021年以来的漏洞。
此外，他们提供的缓解措施与2021年的Proxyshell Powershell RCE问题完全相同：
我当时关于那条路的推文：
我怀疑，从经验来看，今天早些时候它已经在Microsoft进行了完整的分类，因此那里的一些信息会令人怀疑。（（下面更新）
互联网的快速扫描表明，许多组织尚未对Proxyshell进行修补，考虑到交换补丁的工作方式，这是可以理解的（如果您不同意，您可能没有修补交换）。
更新：Microsoft现在已经通过Triage，并发行了CVE-2022–41040和CVE-2022–41082。这是两个新的零日漏洞。似乎从2021年初开始的proxyshell补丁没有解决该问题。当前没有补丁。
我叫这个proxynotshell，因为它是相同的路径，而SSRF/RCE对从当时……但具有身份验证。
他们确实在恶意软件中有一个重要的发现，该恶意软件试图模拟Microsoft Exchange EWS服务：
此外，它调用到137.184.67 [。] 33，该33目前正在运行伪造的RD刚果股票网站，该网站只有1个用户，登录时间为1分钟。自今年八月以来，该网站一直活跃，看起来令人怀疑。
趋势微型具有两天前部署的检测覆盖范围签名，也称其为零一天。
缓解
如果您不在前提上运行Microsoft Exchange，也没有面对Internet的Outlook Web应用程序，则不会受到影响。
您可以通过搜索shodan.io查找http.component：“ Outlook Web应用程序”来查找是否已将Outlook Web应用程序呈现给Internet：您可以添加过滤器org：yourorgname或ssl：“*yourorgname*”来找到您的组织。
Internet跑步Outlook Web应用程序上有很多交换服务器 - 我怀疑许多组织都希望审查风险水平，因为他们通常不再需要它来展示它。
近四分之一的脆弱交换服务器中有四分之一面对互联网，付出或采用。
请注意，剥削需要任何帐户的有效的非Admin（或管理员）凭据。
微软缓解
微软说：“ Microsoft Exchange在线客户无需采取任何行动。”这是错误的 - 如果您运行交换混合动力服务器是Microsoft Exchange在线迁移的标准部分，它们是脆弱的。成千上万的组织也向互联网展示。
Microsoft的交换团队建议您在线使用Exchange如果在线使用：
Microsoft建议禁用远程PowerShell，以换取非Admin用户的交换本指南。出于多种原因，我会谨慎实施此功能 - 包括您不小心限制访问权限，您可以宽泛地限制交换集群。因此，请确保您不申请交换服务帐户和交换管理员。
最终用户需要是交换管理组的成员来使用远程PowerShell，这不是默认配置。
Microsoft确实在更新中提到了一些其他缓解措施，但是由于有效性问题，我尚未提及它们。
补丁
还没有。
打猎
要寻找SSRF到Exchange Management界面，请运行类似的内容（MS Sentinel格式） - 它要求您收集IIS日志。
大师·gossithedog/thereathub threathunting/Exchange-CVE-2021–34473-SSRF·github
要寻找RCE，请运行类似的事情：
大师·gossithedog/thereathting·github
这两个查询都来自2021年，但仍然有效。
我还为Microsoft Defender发表了两个高级狩猎查询，以供端点。这些查找IIS下具有未知流程的任何交换服务器，以及具有PowerShell远程流程的任何交换服务器。
大师gossithedog/thereathting·github
那么总结
- 我可以说肯定的攻击有一直在与这些模式匹配的交换服务器上发生
- 我不能确定这是零一天，提供了信息 - 对我来说，它看起来更加近距离。更新：报废，微软说它们是两个新的零天。
- 提供的信息可能未完成，或者可能在某处进行补丁回归，目前尚不清楚
- Microsoft，ZDI和GTSC需要交谈
- 一些恶意软件（我说的是后门部分）播种了全新的
- 我将继续向这篇文章更新更多信息
- 与往常一样，保持冷静并继续前进。
〜G
更新
2022年9月30日，BST
微软已发布了博客文章。
2022年9月30日bst
添加了防御者狩猎查询。
2022年10月1日，BST
微软已隐身从其博客中删除了这种缓解措施：
存档链接。如果您有网络团队来缓解RCE，不要认为这是有效的缓解措施。
如果您在2021年9月以后提供的交换累积更新，则Microsoft部署了交易所紧急缓解服务（EEMS）更新，以试图阻止攻击，如果您的系统符合条件。
要检查此问题，请转到管理工具 - > IIS管理器 - >站点 - >默认网站，然后单击URL重写。如果您看到以下内容，则将部署。
Microsoft已提供了交换本地缓解工具V2（EOMTV2），您可以用来减轻任何受影响的Exchange版本。该工具如下：
EOMTV2 - Microsoft - CSS-Exchange
该工具必须手动运行。请注意，此工具需要以下安装才能正常工作：
在Windows（Microsoft.com）中更新通用C运行时
2022年10月3日BST
Microsoft缓解使用URL重写（通过EOMTV2和EEMS以及在手动缓解中交付）很容易绕开。GTSC的视频，原始发现者：
作为Jang找到。微软可能应该查看要交换的源代码。
更好的缓解措施：
另外，添加一个从{http_cookie}的规则}包含email = autodiscover的规则，以终止连接。
微软有删除了建议放弃在本地交换并使用其安全博客中现代身份验证MFA的遗产验证交换本地不支持现代身份验证，在2022年太空一年：
2022年10月4日 - BST上午11点
微软未能确认他们的缓解途径。我已经发布了一个视频，详细介绍了所涉及的风险：
Greynoise请参阅24个IP地址扫描Proxynotshell脆弱系统，其中22个IPS被标记为恶意：
2022年10月4日bst
微软已纠正了旁路的缓解指南：
他们没有提到缓解措施很容易绕过。
如果您手动应用此缓解措施您需要手动*改变*上面的缓解字符串。如果您运行了eomtv2， 你需要重新负载脚本和再次运行。EOMTV2网站不说脚本已更改- 因此，请确保您的管理员具有正确的脚本。
旁路是：
问题的来源是 - Microsoft Exchange的源代码替换为 @，Microsoft不知道。
所有这些都是您的交换服务器没有受到保护的“因此”，如果您还没有安装EEM或手动应用新的缓解措施，仍然不会受到保护……因此，我们再次开始周期。
2022年10月5日bst
现在有缓解缓解措施的缓解措施的旁路。
Microsoft忘记在IIS URL重写中启用URL解码，因此您可以将P PowerShell中的P编码为％50：
我在今天的Exchange服务器上观察到了这一点，他们两者都使用。
fix =将URL重写规则更改为：
2022年10月5日bst
发现Proxylogon的Volexity将这项活动归因于以下线程中的中国威胁行为者：
这个威胁参与者在Zimbra电子邮件解决方案中也有零一天。
另外，有两名已知的受害者是土耳其贸易部和土耳其工业和技术部 - 都运行交换服务器呈现给互联网。
2022年10月6日上午11点
目前有31个IP扫描互联网以供Proxynotshell脆弱系统，其中27个被标记为恶意。灰色：
微软再次更新了他们的缓解，以处理缓解缓解措施的旁路，以上提到：https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
手动应用缓解措施或RAN EOMTV2脚本的Exchange Server用户应使用上面的指南重新应用缓解措施。
2022年10月7日，BST
人们发现，缓解措施绕过缓解措施的缓解措施还有另一个旁路。稍后详细信息，但微软可能想检查以下代码：
public static bool isautodiscoverv2previewrequest（string path）{grogng validator.throwifnull（“ path”，path）;return path.endswith（“/autodiscover.json”，stringcomparison.ordinalignorecase）;}
此外，Microsoft检测到这种威胁的许多签名都取决于监视w3wp.exe，又名IIS。这是子过程产生的地方，写下（和读取）等。
但是，存在一个很大的问题 - 如果您使用Windows Server 2016或更高版本，Microsoft在安装IIS时会自动排除W3WP.EXE - Exchange Server确实可以：
上面的另一个亮点是排除了IIS临时文件夹，这是.NET对象（常见作为Exchange利用人工制品）实时的。
这适用于Microsoft Defender的免费版本，以及端点的Defender（以及云/服务器变体）。
结果是Microsoft的遥测是不完整的，并且没有正确检测到Webshells，这可能解释了为什么在这种野外使用的wiverustotal，在Virustotal上易于检测到的原因。IIS没有受到监控。
这些排除在盒子上不可见，也不可在Microsoft Defender中使用Endpoint的门户。
纠正此问题的唯一方法是关闭自动排除：
但是，微软特别建议不要这样做。
2022年10月8日 - 午夜BST
Microsoft发布了另一个手动缓解，EOMTV2脚本和EEMS Update，以涵盖我以前的条目中的旁路。
技术问题是，如果AutoDiscover.json在请求的末尾，则代码将接受任何内容。因此，您可以在请求较早地粘贴 /Powershell。
这是来自MS Exchange来源：
因此，您可以要求：
/autodiscover/admin..localhost/powershell/autodiscover.json?blah=foo
交换条将其拆下并仍在处理，并且由于PowerShell并没有结束，因此它不符合先前的正则表达式。
2022年10月9日，bst
缓解措施已由MS再次更新。
REGEX从：
（？=。*autodiscover.json）（？=。*PowerShell）
到：
（？=。*自动发现）（？=。*PowerShell）
此外，一个新的Webshell文件名：
2022年11月8日，格林尼治标准时间
微软终于发布了一个补丁。前往有关此的安全更新以获取补丁程序（您需要进行支持的累积更新才能进行补丁）。
CVE-2022–41082 - 安全更新指南 - Microsoft - Microsoft Exchange Server远程代码执行漏洞
