为了应对日益复杂的安全问题，微软采用了各种技术、服务、集成、应用程序和配置。虽然这样做的效果很好，但与此同时，却产生了另外一个问题，即管理越来越复杂和精细，而管理上稍有不慎，就有可能发生各种连锁后果。虽然将所有内容都转移到云端，可以在可扩展性、功能性甚至效率方面降低这种管理的复杂性，但却可能出现其他的问题。为此，在过去的一年里，有研究者就以微软作为他们的云提供商，来测试其中可能出现的漏洞。

事实上，测试者读的关于微软产品和服务的说明书越多，测试者就越觉得失落。虽然在过去的一年里，测试者能够灵活运用这些技术，预防各种攻击，但其中的一些概念却还是令他们感到疑惑。比如，默认配置是什么?是默认提供的吗?这种配置是同步的吗?当测试者私下分享了其中的一些技巧后，一个新问题就会随之而来。

微软的安全环境的变化

运行了多年的Microsoft Active Directory和Exchange on-prem，可以快速给Office客户提供一些内部应用程序的webmail门户、Sharepoint和SSO的访问权限。在此过程中，如果企业决定将业务迁移到office365，则再正常不过了! 而企业的所有用户都可以使用他们的网络凭据进行身份验证。此时，微软势必会提供数量惊人的集成，但是企业怎么知道他们是否正确的管理了一切?

各种复杂情况的出现

管理Microsoft AD，可以利用Azure AD，而管理邮件，则有Exchange on-prem。如果你想要完整的Microsoft Office套件，用office365就可以了。由于Office 365是付费的，企业还可以获得Skype和OneDrive等服务。虽然SMS令牌是默认的传递机制，但出于某种原因，企业的用户仍然可以使用Outlook进行身份验证，而不需要 Azure MFA多重身份验证。

而在上述的例子中，就会出现了许多问题，比如在防御或应对多种不同的攻击方面，包括远程转储活动目录、绕过甚至劫持用户的多因素身份验证，企业几乎无任何招架之力。

了解谁是组织部门内的人员通常是在通过第三方服务（如LinkedIn或其他OSINT技术）参与的侦察阶段完成的。对于攻击者，他们要做的就是了解组织的许多深度细节，比如企业内网配置了哪些组以及这些组的成员。这对于成功选择攻击的计算机目标并根据用户的访问目标定位用户至关重要。但是，如果攻击者不在内部网络中，就需要费很大的力气确定目标用户?那如果组织的详细信息托管在云中，且攻击者根无法访问内部网络，那是不是就安全了呢?

对于微软来说，如果你利用Active Directory (on-prem或Azure)使用任何微软的云服务(Office 365, Exchange Online等)，攻击者只需利用一个登陆凭证，就可以通过Azure AD盗取你的整个Active Directory结构。步骤如下：

1. 对企业的Webmail门户进行身份验证（即https://webmail.domain.com/）；

2.将浏览器URL更改为:https://azure.microsoft.com/；

3.从活动会话中选择目标帐户；

4.选择Azure Active Directory；

如果测试者们能够导出所有用户和组，则他们就会有一个非常完整的企业员工表单，以及他们所属的组。测试者们还可以了解到VPN、域管理、数据库访问、云服务器或财务数据登录的具体组。Azure AD的另一个特点是它可以保存每个用户的设备信息，这样测试者们就可以看到他们是否在使用Mac、Windows或iPhone，以及具体的版本信息，比如Windows 10.0.16299.0。除此之外，测试者们还可以了解到所有业务应用程序及其终端、服务名称、其他域名，甚至用户可以访问的虚拟资源(即虚拟机、网络、数据库)。

对Azure门户进行身份验证的另一个漏洞是，攻击者可以创建一个后门，即  “Guest” 帐户。步骤如下

1.点击 “Azure Active Directory”；

2.在“管理”一栏下单击“用户”

3.点击“New Guest User” 邀请自己；

根据设备的配置，攻击者可能会同步到内部网络，也可能不会同步到内部网络。事实上，默认情况下，创建“Guest” 帐户时会启用同步过程，并允许“Guest” 帐户通过身份验证，在内部注册设备和VPN。这是一个重要的配置组件，因为它可能会造成非常大的漏洞。

Azure的信息泄露过程

通过web浏览器访问Azure门户时，测试者是没有找到直接导出信息的方法。于是测试者开始编写一个可以进行身份验证的工具，它会以一种自动化的方式进行验证，但这个过程还是很麻烦。以下是测试者利用的一些方法：

Azure CLI (AZ CLI)

作为一个Linux用户，测试者很自然地被AZ CLI所吸引。部分原因是因为测试者会将尽可能多的数据导入到单行程序中，另一部分原因是因为测试者在.NET中编写的工具。而使用AZ CLI是一种针对Azure的OAUTH进行身份验证的快速简便方法，同时还可以快速导出原始数据。在本文中，测试者们将重点讨论这个解决方案。

Azure Powershell

随着强大的Powershell工具，如Powershell Empire和MailSniper的兴起，测试者很惊讶Azure Powershell还没有成为类似的工具。有大量的Active Directory cmdlet可供交互，如果要使用Azure Powershell，只需安装Azure RM Powershell，然后运行:Connect-AzureRmAccount

Azure .NET

让Azure .NET库与Active Directory交互是非常有创意的，不过测试者还没有深入研究这些库，但从更高层次来看，这些库似乎是Active Directory Graph API的某种包装器。

正如前面提到的那样，本文将重点讨论如何测试者使用AZ CLI与Azure进行交互。测试前，他们必须首先使用Azure建立一个活动会话。对于使用微软或谷歌服务的企业来说，攻击者很少尝试直接访问内部网络上的shell。所以，测试者通常会使用一个他们自己编写的名为CredSniper的工具来获取网络凭证和多因素令牌，然后在追踪敏感电子邮件、文件、访问信息和VPN。

只有这样，测试者们才会假设他们已经以某种方式获得了有效凭证。

安装AZ CLI

测试者需要将Microsoft源代码添加到apt(假设是Linux)，安装Microsoft签名密钥，然后安装Azure CLI。

AZ_REPO=$(lsb_release -cs) echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" | sudo tee /etc/apt/sources.list.d/azure-cli.list

curl -L https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

sudo apt-get install apt-transport-https

sudo apt-get update && sudo apt-get install azure-cli

通过Web会话进行身份验证

在正确安装之后，测试者需要使用已经获得的凭据为Azure创建一个会话。最简单的方法是在普通浏览器中使用ADFS或OWA认证。

az login

这将在本地生成OAUTH令牌，打开身份验证页面的浏览器选项卡，让测试者根据已经通过身份验证的帐户选择一个帐户。选择好帐户后，服务器将验证本地OAUTH令牌，除非它们过期或被销毁，否则测试者不必再次执行此操作。测试者还可以传递-use-device-code标志，该标志将生成他们提供给https://microsoft.com/devicelogin的令牌。

转储用户

现在进入测试者最喜欢的部分——转储用户。目前有许多技术可以提取GAL，例如在OWA中使用FindPeople和GetPeopleFilter web服务方法。这些技术对于测试者来说是很好的资源，但是这些技术在提取可用的数据、枚举用户时需要很长时间，再加上所需的web请求数量很大。所以使用AZ CLI，可以非常轻松地提取每个用户的所有目录信息。在下面的示例中，测试者使用JMESPath过滤器来提取感兴趣的数据，除此之外，提取的数据还可以导出为表格、JSON或TSV格式。

转储全部用户

az ad user list --output=table --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name:displayName,Title:jobTitle,Department:department,Email:mail,UserId:mailNickname,Phone:telephoneNumber,Mobile:mobile,Enabled:accountEnabled}'

转储感兴趣的用户

如果你知道目标帐户的UPN，则可以通过传入-upn标志来检索特定帐户。如果你想要深入了解特定帐户的Active Directory信息，那么这很方便。在下面的示例中，测试者提供的是JSON格式，而不是表格形式。

az ad user list --output=json --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name:displayName,Title:jobTitle,Department:department,Email:mail,UserId:mailNickname,Phone:telephoneNumber,Mobile:mobile,Enabled:accountEnabled}' --upn='<upn>'

转储组

测试者利用转储组函数，可以了解企业如何使用组，来对业务领域、用户和管理员身份进行管理。AZ CLI提供了一些有用的命令，可以帮助测试者实现这一目的。

转储所有组

测试者通常做的第一件事就是导出所有组，然后才对某些关键词进行grep处理，比如Admin、VPN、Finance、Amazon、Azure、Oracle、VDI、Developer等。虽然还有组的其他元数据可用，但测试者倾向于只获取名称和描述。

az ad group list --output=json --query='[].{Group:displayName,Description:description}'

转储感兴趣的组的用户

一旦测试者导出了这些组并挑选了他们感兴趣的，接下来就可以转储这些组的用户了，而这些目标将是网络钓鱼的主要目标。与流行观点相反，测试者并不认为公司里头衔高的人就有很多访问权限，他们认为后端工程师和研发团队人员，往往拥有最多的访问权限，因为他们往往利用外部网络就可以进入内部系统。

az ad group member list --output=json --query='[].{Created:createdDateTime,UPN:userPrincipalName,Name:displayName,Title:jobTitle,Department:department,Email:mail,UserId:mailNickname,Phone:telephoneNumber,Mobile:mobile,Enabled:accountEnabled}' --group='<group name>'

转储应用程序和服务

微软提供的另一个很好的特性是能够让用户注册使用SSO/ADFS或与其他技术集成的应用程序。许多公司将其用于内部应用程序，对于攻击者来说，这也是个攻击突破口，因为与应用程序相关的元数据可以提供更加精细的目标信息，比如url。

转储所有应用程序

az ad app list --output=table --query='[].{Name:displayName,URL:homepage}'

转储感兴趣的应用程序

在下面的截图中，你可以看到测试者通过检查与Azure中注册应用程序关联的元数据获得了Splunk实例的URL。

az ad app list --output=json --identifier-uri='<uri>'

所有服务的负责人

az ad sp list --output=table --query='[].{Name:displayName,Enabled:accountEnabled,URL:homepage,Publisher:publisherName,MetadataURL:samlMetadataUrl}'

具体服务的负责人

az ad sp list --output=table --display-name='<display name>'

使用JMESPath进行高级过滤

在上面的例子中，你可能已经注意到测试者试图限制返回的数据量。这主要是因为测试者只需获得需要的东西，而不是一切可见的内容。AZ CLI处理此问题的方法是将-query标志与JMESPath查询一起使用，这是用于与JSON交互的标准查询语言。在将查询标志与'show'内置函数结合使用时，测试者确实注意到AZ CLI中的一些错误。另一件需要注意的事情是，默认的响应格式是JSON，这意味着如果攻击者打算使用查询过滤器，你需要指定正确的区分大小写的命名规则。因为不同格式的名称命名规则却是会有有一点不一致，如果使用表格格式，当JSON该小写的时候，它可能会变成大写。

禁用对Azure门户的访问

测试者花了一些时间试图弄清楚什么该禁用、如何阻止访问、如何限制、监控什么，才能起到更好的安全防护。在此，测试者将提供一种禁用Azure Portal访问用户的方法。不过这种方法，测试者还没有亲自测试过它的可靠性，也不确定该方法是否也会禁用AZ CLI、Azure RM Powershell和Microsoft Graph API。步骤如下：

1.使用全局管理员帐户https://portal.azure.com登录到Azure；

2.在左侧面板上，选择“Azure Active Directory”；

3.选择“用户设置”；

4.选择“限制对Azure广告管理门户的访问”；

另一种方法是查看条件访问策略：https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

总结

现在有很多不同的工具可以测试AWS环境的安全性，甚至是最近出现的用于捕获SharpCloud等云凭据的新工具也可以，而云环境似乎是一个经常被忽视的攻击载体。

目前，测试者已经发布一个用于与云环境交互的攻击框架，名为CloudBurst。它是一个可插入的框架，使渗透测试者能够与不同的云提供商交互，以捕获、破坏和盗取其中的数据。