摘要

在我的文章《攻击 Azure，Azure AD 及 PowerZure 介绍》中，我提供了几种攻击 Azure 和 AzureAD 的策略、技术和过程(TTPs) ，并发布了利用 PowerZure 来自动化操作其中的一些内容。 我坚信，当一个新的战术或工具开发出来后，防守指南应该遵循以帮助蓝队从这些战术或工具中获得安全感。 不幸的是，Azure 对于发生在 Azure 内部的操作的日志记录能力还有很多不足之处。

本文的目的是对 Azure 内部的原生活动日志服务功能进行概述，并深入探讨如何检测我上一篇文章中列出的许多 TTPs，以及关于如何从活动日志服务中获取更多细节的建议，而不仅仅是显示在‘ summary’选项卡上的内容。

概览

每当一个操作在 Azure 中完成，一个事件就会生成并保存在活动日志服务中。 在活动日志中，用户可以看到所有操作并应用基本过滤器(时间跨度、严重性等)。 日志中的操作(事件)是根据操作的状态分离出来的，即事件何时开始、何时更新、何时结束等等。 为了查看该操作中的其他“子事件” ，用户必须单击该事件，然后其他状态事件将填充。 这很重要，因为围绕操作的细节取决于状态。

图1: 单击第一个事件会显示一个子事件

例如，当一个用户被分配到一个角色(例如 contributor)时，会启动一个创建事件的操作，但是缺少必要的细节。

图2: 在 Azure 中为角色分配创建的初始事件

一旦操作完成，另一个“子事件”会被创建，然后公开必要的细节。

图3: 单击子事件时会显示更多的详细信息

在本例中，“ Message”字段包含添加到角色的用户的用户名，与不包含此信息的原始事件相比较。

警报

可以从活动日志中直接配置警报。 每当一个操作发生时，Azure 都会给出一个选项，一旦你点击了这个事件，就可以为这个操作创建一个警报。

图4: 基于事件创建新警报的选项

在创建规则时，可以选择更改条件。 当保留默认条件时，它是一个非常常见的条件，如图5所示：

图5: 条件被设置为成功的任何信息级的事件。 这将产生几个良性警报

条件可以通过点击垃圾桶图标和点击条件下的“添加”来改变。

图6: Runbooks 的警报条件

从这里，可以将警报操作设置为几个选项。

图7: 警报选项

细节决定一切，是吗？

获取一个常规事件对于警报非常有用，但是对于分析人员来说，拥有与该事件相关的细节是非常关键的，比如谁开始了操作，操作的目标对象是什么，等等。 不幸的是，有几个操作报告的细节信息很少。

命令执行

在虚拟机上运行命令时，会创建一个事件，但是没有记录运行的命令。

图8: 在 VM 上运行命令的事件中返回的所有内容

摘要选项卡显示了命令的执行时间和执行者，但是为了查看执行时 VM 的名称，用户必须进入 JSON 选项卡并查看‘ id’属性才能查看事件的作用域。

图9: 作用域路径中 VM 的名称

无论何时向 Windows 虚拟机发出命令，Azure 都将输入的命令作为 PowerShell 脚本存储在内部端点上

C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows\1.1.3\Downloads

如果攻击者没有删除脚本，这就允许分析人员可能看到在虚拟机上运行了哪些命令。 当然，我总是建议你使用额外的防御工具，并在组策略中对这些端点启用脚本块日志记录。

钥匙库

由于其用途，钥匙库在 Azure 中非常敏感。 它们可以存储证书、密码和密钥，因此它们也应该受到严密的访问监控。 进入钥匙库不会产生事件，也不会泄露密钥。 这就是这个资源与以角色为基础的存取控制的预期目的; 就 Azure 而言，如果用户访问他们有权访问的资源，它就不值得记录事件。 钥匙库仅限于其所有者，由所有者编辑访问策略，允许其他用户访问该钥匙库。 但是，作为全局参与者（Global Contributor），用户可以编辑任何钥匙库的权限并允许自己访问该钥匙库。 这确实会产生一个事件，“更新钥匙库”。

钥匙库更新时的日志

事件摘要显示了谁更新了保险库的权限，但是保险库的名称在 JSON 输出中而不是摘要中。

图10: JSON 选项卡中的作用域显示了库名称

这样做的主要问题是，它没有显示谁被添加到访问策略中。 因此，确定谁被添加的唯一方法，就是进入每个保险库并确定访问策略上的所有用户是否都应该在那里。

Runbooks

在 PowerZure 中，一个利用 Runbook 优势的函数是 Create-Backdoor。 这是通过创建一个 Runbook 来实现的，该 Runbook 将提供一个新帐户，并在执行时将其分配给 Contributor 角色。 它不是自动执行，而是生成一个 Webhook URI，这个 URI 可以传递到 Execute-Backdoor，这个 Execute-Backdoor 将根据需要运行 Runbook。 这需要管理员角色，因为只有管理员可以在 Azure AD 中创建用户。 幸运的是，创建 Runbook 会生成几个事件，因此可以直接检测这些事件。 第一个关键事件，是创建 Runbook，然后创建 Webhook，然后生成该 Webhook 的 URI。

图11: PowerZure 中“ Create-Backdoor”的操作序列

这样做的问题是，‘event initiated by’字段是不正确的。 如果 Runbook 是从命令行创建的，则该字段始终由租户管理员(而不是实际创建 Runbook 的人)填充。 为了确保我的头脑清醒，我用三个不同的帐户测试了它，每次事件由我的管理帐户发起，即使它没有登录到任何地方。

图12: 由字段启动的事件显示了通过 CLI 创建 Webhook 和 Runbook 时的租户管理员，而不是实际用户

截止 2020年1月24日，这个 bug 已经提交给微软，我现在正在等待他们的回复。

分组任务

即使本地活动目录(AD)与 AzureAD 同步，也不可能将用户添加到本地 AD 组。 然而，将用户添加到 Azure 的 Azure 组中并不会在活动日志下生成事件。 Azuread 有自己的事件查看器，称为审计日志。 这确实提供了操作的必要细节，但是在 AzureAD 中不能为这些事件配置警报，除非正在使用 Log Analytics 服务，并且 AzureAD 被配置为向 Log Analytics 发送日志。 然后警报将不得不从日志分析生成，而不是 AzureAD 的审计日志。

虚拟机磁盘

如果攻击者侵入了一个全局参与者（Global Contributor）的帐户，他们可能会生成一个下载 VM 磁盘的链接。 这可以通过操作名“获取磁盘 SAS URI”检测到。 摘要或 JSON 选项卡中没有显示链接，磁盘是否实际下载也没有显示链接。 只创建一个泛型事件，除了磁盘名之外没有其他详细信息。

防御方法

由于 Azure 使用了以角色为基础的存取控制访问控制(RBAC) ，它应该被视为类似于本地 AD 组成员，这意味着它应该遵循最少特权访问的方法。 将 Global Contributor 角色分配给用户可以为用户提供大量的访问和执行能力。 建议检查在 Azure 中哪些角色实际上是操作所必需的。 Azure 包含许多“全球”角色之外的内置角色，可以在这里查看。 此外，定制角色的创建可能更适合企业的需要。

遵循最低特权访问的方法，Azure 确实提供了特权身份管理(Privileged Identity Management，PIM)服务，但是要付出一定的代价，但是我们强烈推荐这种服务。

组织希望尽量减少能够访问安全信息或资源的人数，因为这样可以减少恶意行为者获得该访问权限的机会，或者减少授权用户无意中影响敏感资源的机会。 然而，用户仍然需要在 Azure AD、 Azure、 Office 365或 SaaS 应用程序中执行特权操作。 组织可以向用户提供对 Azure 资源和 Azure AD 的即时(JIT)特权访问。 有必要监督这些用户使用管理员权限所做的事情。 ——微软

PIM 类似于特权访问管理(Privileged Access Management，PAM)解决方案，它只在需要时提供管理或特权访问。 PIM 可以在每个资源的基础上使用。 在 PIM 面板中，有三个类别: 合格的、活动的和过期的。 “合格”意味着用户可以请求访问该资源上的该角色。 活动意味着用户主动拥有该角色并且不需要批准。 过期意味着不再允许用户请求对该角色的访问，并且不再拥有该角色。

图13: ‘ Contrib’用户允许请求对资源的 contributor 角色的访问

例如，如果一个用户为了一个虚拟机资源被添加到 PIM 中，并且有资格请求访问 Contributor 角色，那么该用户只需要请求激活该虚拟机的特权，而不必为所有其他用户这样做。 由于角色是层次化的，如果将 PIM 放在订阅上，那么它将影响该订阅中的所有资源。 使用 PIM，默认情况下不允许请求被批准。

图14: 角色的默认激活设置

这意味着默认情况下，用户可以随时激活他们的角色。

然而，PIM 的日志记录在活动日志中有适当的详细说明。

图15: 当用户激活他们的 PIM 控制角色时的事件摘要。Reader 激活了角色‘Contributor’为订阅‘ Azure Test’

最后的想法

Azure  提供了一些额外的服务，可以让你对资源中的操作有更深入的了解，比如 Log Analytics 和 Azure Sentinel，然而 Azure 本身的操作日志记录并不完美。 希望微软能在活动日志中实现更多的细节，这样维护者就可以了解事件的全貌，而不需要额外的努力。

本文翻译自：https://posts.specterops.io/detecting-attacks-within-azure-bdc40f8c0766如若转载，请注明原文地址：