0x01 前言

在过去的几年时间里，我们都是在分享关于本地域环境的横向移动技巧，比如 BloodHound ，它可以通过映射本地 Windows 计算机、本地管理员和登陆的与用户来收集，并将结果进行可视化，列举出有可能进行的横向移动路径。

因此我也很好奇，这类方法是否可以在 Azure AD 环境中进行实践？答案是可以的。在 Azure AD 环境中，计算机和用户都在云环境中进行管理。同样，在这些计算机中收集其它用户的凭证并进行模拟，也是可行的。

本文中将讲解 Azure AD 与 本地域环境之间的差异，如何将应用于本地域环境的技术能作用于 Azure AD环境。

0x01 Mimikatz 的作用

尽管转存用户登陆凭证并不是模拟该用户的唯一方法，但是在 Mimikatz 2.2.0-20190720 的发行版中，已经支持转存 Windows 10（内部版本为 17763.615）中 lsass.exe 进程的内存空间，其中包括 Azure AD 上的计算机。

在已加入 Azure AD 的计算机中，用户在 Azure AD 环境中输入用于身份验证的凭证，该凭证经过 RC4 存储在 lsass.exe 中，而 Mimikatz 2.2.0 可以转储它们。

<center>从已加入 Azure AD 环境的计算机中使用 Mimikatz 转存凭证</center>

0x01 云环境与本地环境的区别

在讨论横向移动问题之前，我想先说明一下加入 Azure AD 中的计算机与加入本地域环境的计算机之间的差别，这样对于技术差别上更加容易理解。

2.1、认证协议

在上个章节获取该 NTLM 哈希时，我觉得我成功了，可通过哈希传递就可以进行横向移动。但是，实际上在 Azure AD 环境中并没有本地域控制器，所以该环境并不支持 Kerberos 和 NTLM 认证，因此，如果不将该 NTLM 哈希进行破解，该 NTLM 哈希则将毫无价值。这就是最重要的区别之一

2.2、用户表达式的区别

在 Azure AD 环境中，用户名的 FQDN 表示为：user@directory name.onmicrosoft.com ，而本地 AD 环境的用户则表示为：Domain\User

2.3、 用户账号标识的区别

在 Active Directory 环境中，用户账号在 DC 上和在用户计算机上的本地 SAM 中都是使用安全标识（SID）表示，但是在 Azure AD 环境中，用户账号则使用 GUID（又名 Azure AD id）表示，该 GUID 与原始 SID 不同，该原始 SID 仍代表端点上的账户。而为了克服这种差异情况，并使得 Azure AD 账号可以成为 Windows 计算机上的本地组成员，则需要将 GUID 转换为 SID 这种表示形式。

通过将 “S-1-12-1-” 与 GUID 的简单拆分处理后进行组合是可以将用户的GUID 转换成 SID 的：

[base16(a1)]-[base16(a2)]-[ base16(a3)]-[base16(a4)]
S-1–12–1-[base10(a1)]-[ base10(a2)]-[ base10(a3)]-[ base10(a4)]

例如：当GUID 为 6aa89ecb-1f8f-4d92–810d-b0dce30b6c82 时，转换后为 S-1–12–1–1789435595–1301421967–3702525313–2188119011

<center>Azure AD 用户的 ID</center>

<center>将十六进制 ID 转换，以构建用户 SID</center>

2.4、本地管理员组

本地计算机 SAM 数据库使用的是用户和组转换后的 GUID（也就是最后的 SID）。默认情况下，Azure AD 的两个管理角色（“Global administrator” 和 “Device administrator” ）以及计算机的所有者（执行加入 Azure AD 过程的账户）是本地 Administrators 组成员。

<center>转换后的 ID 作为 Azure AD 计算机上的 SID 表示形式</center>

简单总结下区别：

• Azure AD 环境的身份验证协议不是 Kerberos 和 NTLM
• 用户的 FQDN 表示不同
• 默认情况下，加入 Azure AD 的计算机中，会设置新的本地管理员组
• Azure AD 用户在计算机的 SAM 数据库中的表现形式不同于本地活动目录中的有效 SID，而是云用户 ID 的表示形式

0x02 计算机间的认证协议

上个章节提到 Azure AD 组成员和计算机的所有者是本地管理员，因此可以模拟系统账号，转存 lsass.exe 的内存，进一步查找其他已登陆过的用户的凭证。

<center>从已加入 Azure AD 环境的计算机中使用 Mimikatz 转存凭证</center>

尚未解决的问题是：如何在已加入 Azure AD 环境的计算机上模拟具有本地管理员权限的登陆用户。

• Token 操作可能是一个很好的解决方案，但是 Windows 10 不支持。
• PTT、PTH 要求 Kerberos、NTLM 协商，但 Azure AD 均不支持这两种协议。

现在，我想知道两台 Azure AD 的机器之间是怎么进行身份验证的。自 Windows 7 和 Windows Server 2008 R2 之后，安全服务提供程序（SSP）就支持对加入 Azure AD 的计算机之间进行进行身份验证，例如，在 Azure AD 环境中的 NEGOEX PKU2U（基于公钥密码的 User-to-User）。

对于我们而言，很希望可以通过网络进行身份验证。

SMB2 身份验证协商可以依赖于 Kerberos 协议扩展、NTLM 身份验证协议，又可以依赖于简单和受保护的 GSS-API 协商（SPNEGO）。因此通过 GSS-API 协议 Challenge/Response 扩展机制 NEGOEX PKU2U，如下图及微软官方的网络数据包分析所示:

NEGOEX PKU2U 是基于 Kerberos PKINIT 消息，该消息还用于本地域环境中的智能卡身份验证。在请求远程计算机（已加入Azure AD ）进行身份验证时，从联机 ID 提供程序（AKA Azure AD）中获得一个用户证书，该证书针对特定用户颁发了一个小时时限的证书，并使用联机 ID 体统程序的 CA 私钥进行签名。

为了允许证书验证，计算机在 P2P 的连接过程中获得 联机 ID 证书的公共对，当 Kerberos 应用程序请求验证用户的真实性时，远程 Windows 计算机将使用 CA 配对的公钥验证签名时间戳和随机数据（也称为“authenticator”），以验证用户证书的真实性。

<center>服务器上的 CA 的权限</center>

<center>带有私钥的客户证书</center>

由于 Mimikatz 能够使用本地管理员权限来转存客户端的证书以及私钥，因此一旦获取这些凭证，通过 NEGOEX PKU2U 来模拟用户将会变得非常简单。

在另外的机器上模拟另一个计算机账号似乎更可行，因为该计算机账号的证书在长达一年的时间内都是有效的，但是我不确定它会（能）在域中做什么。

<center>使用 Mimikatz 在已加入 Azure AD 的计算机上转存证书</center>

0x03 结论

综上所述，Azure AD 环境与本地 AD 有着巨大的区别，它不再基于 Kerberos KDC 和 NTLM。计算机上的用户表示已更改，并且每台加入 Azure AD 的计算机上都默认有本地管理员。但是，就算如此，Azure AD 环境仍然会受到横向移动的技术攻击。

原文：https://medium.com/@talthemaor/moving-laterally-between-azure-ad-joined-machines-ed1f8871da56