Azure AD计算机之间横向移动
作者：Sec-Labs | 发布时间：
正文内容
这篇文章是由微软安全研究员Nirit Tyomkin（@NiritTyomkin）共同撰写的。
在过去的几年里，我们一直在处理内部域环境中的横向移动问题--例如，Bloodhound通过映射内部Windows机器、本地管理员和登录的域用户来收集和可视化可能的横向移动。
我很好奇，用类似的方法在Azure AD机器之间横向移动是否仍有可能，简短的回答是：是的！有可能。
本地管理员的关系，可以收获Windows机器上其他用户的凭证并冒充他们，在Azure AD环境中也会发生，机器和用户都在云环境中管理。
虽然倾销凭证不是冒充用户的唯一选择，但Mimikatz 2.2.0-20190720的发布是在Windows 10（build 17763.615）包括Azure AD加入的机器上处理lsass.exe内存空间。
在Azure AD加入的机器中，用户输入其凭证，用于在Azure AD面前验证用户。为了支持这一点，RC4凭证存储在lsass.exe中，Mimikatz 2.2.0可以转储它们。
在Azure AD加入的机器上运行Mimikatz，如下图所示
起初，我想--"太好了"，通过Pass-the-hash或Over-pass-the-hash可以进行横向移动。然而，Azure AD环境中没有内部域控制器，Kerberos和NTLM在这个环境中不被支持。因此，如果不执行BruteForce来获得明确的证书，RC4就没有价值。
在我们讨论横向移动的问题之前，我想讨论一下Azure AD连接机与内部域连接机的一些区别。
首先，Azure AD机器中登录用户的Kerberos境界（域名）是一个常量值 "AzureAD"，用户名是用户的FQDN表示和目录名"'user@directoryname.onmicrosoft.com'"。例如，使用CMD中的runas.exe，在Azure AD用户身上会出现以下情况
Runas /user:AzureAd\User@DirectoryName.onmicrosoft.com cmd与在AD上加入的相同程序相比，使用
Runas /user:DomainName\UserName cmd另一个变化是用户账户识别--在活动目录环境中，一个账户在DC和终端的本地SAM中都有一个安全标识（SID）。然而，在AAD中，账户是用GUID（又称 "AAD Id"）表示的，它与原来的SID不同，SID仍然代表终端上的账户。为了克服这种差异，并允许AAD账户成为Windows机器上的本地组成员，他们的AAD标识需要被翻译成SID表示。
显然，用户的AAD标识通过连接 "S-1-12-1-"到AAD标识的每个部分的十进制表示法来转换为SID
[base16(a1)]-[base16(a2)]-[ base16(a3)]-[base16(a4)]
S-1–12–1-[base10(a1)]-[ base10(a2)]-[ base10(a3)]-[ base10(a4)]例如
6aa89ecb-1f8f-4d92–810d-b0dce30b6c82是
S-1–12–1–1789435595–1301421967–3702525313–2188119011
用户和组的AADID都被本地机器的SAM数据库使用。默认情况下，两个AAD管理角色全局管理员角色和设备管理员角色以及机器的所有者，即执行AAD加入过程的账户，是本地管理员组的成员。
简要回顾一下到目前为止提到的差异
在AAD环境中，Kerberos和NTLM不是主要的认证协议。
在AAD加入的机器上有新的本地组管理员的默认设置。
AAD用户在AAD加入的机器的本地SAM中的表示不是目录中的有效SID，而是云用户ID的表示。
回到横向移动的问题--提到的AAD组的成员和机器的所有者默认为本地管理员，因此可以冒充系统账户，转储lsass.exe内存并找到其他登录用户的证书。
悬而未决的问题是如何在AAD连接的机器上冒充具有本地管理权限的登录用户--令牌操作可能是一个选择，但在Windows 10上不支持；Pass-The-Ticket、Pass-The-Hash需要Kerberos或NTLM协商，而这两者在Azure AD环境中不支持。
然后，我想知道两个Windows AAD加入的机器之间的认证是如何进行的。显然，从Windows Server 2008 R2和Windows 7开始，就有一个安全服务提供者（SSP）支持，处理两个AAD连接的机器之间的认证，就像在AAD环境中一样--NEGOEX PKU2U（基于公钥加密的用户到用户）。
对于那些喜欢看网络认证的人来说，SMB2认证协商是基于GSS-API扩展的挑战响应机制NEGOEX PKU2U，如下图所示，在网络数据包分析中也有。
NEGOEX PKU2U是基于Kerberos PKINIT消息，这也用于内部目录环境中的智能卡认证。在请求与远程AAD加入的机器进行身份验证时，在线ID提供商（又称Azure AD）会获得一个用户证书，该证书是为特定用户颁发的，时间范围为一小时，并以在线ID提供商的CA私钥签名。
为了允许证书验证，对等计算机在机器的加入过程中获得在线ID证书的公共对。当Kerberos应用程序请求验证用户的真实性时，远程Windows机器，使用CA配对的公钥验证签名时间戳和随机数据（又称 "验证器"）将用于验证用户的证书真实性。
因为Mimikatz能够使用本地管理权限转储客户的证书和它的私钥，一旦你获得这些证书，通过NEGOEX PKU2U冒充用户是很简单的。从另一台电脑上冒充计算机账户似乎更可行，因为计算机账户的证书有效期更长，为一年，但我不确定它能让你在域内做什么。
总而言之，Azure AD环境与内部部署的AD相比有了巨大的变化。它不再是基于Kerberos KDC和NTLM。机器上的用户代表已经改变，每个Azure AD加入的机器上都有默认的本地管理员。然而，Azure AD加入的机器仍然可以被那些想冒充Azure AD用户并在Azure加入的机器之间横向移动的对手所挑战。对手需要为他们解决一个新的挑战，并每小时收获凭证以获得有效的用户证书。