调查跨租户的同步化攻击

简介

2023年1月31日，微软宣布了一项名为跨租户同步（CRS）的新功能。通过CRS，你可以在两个租户之间实现用户和组的同步。下面的图片显示了三个租户之间的CRS。

由于这是一个非常新的功能，而且仍在预览中，所以还没有观察到攻击，但它肯定有被滥用的可能。在这篇博客中，我们将告诉你如何执行和调查可能的CRS攻击。

场景

使用CRS可能是一种有趣的持久性方法，也是威胁者在Azure环境中隐藏自己的存在并保持持久性的一种方式。此时此刻，我们只能推测攻击的情况，但让我们遵循假设突破原则。一个威胁行为者成功攻破了一个Azure租户，并希望保持继续访问。在攻击者控制的租户和受害者租户之间设置跨租户同步可能有助于实现这一目标。要执行这种攻击，威胁者需要在他们的目标（受害者）租户和源（威胁者）租户上进行配置。为了配置CRS，需要采取一些步骤，下表显示了所需的步骤，它取自微软网站。

在我们的方案中，我们将目标租户称为受害者租户，源租户称为攻击者租户。

攻击与防守

第1步 - 启用受害者租户以允许跨租户访问

第一步是由威胁者在受害者租户中启用CRS，要做到这一点，威胁者需要有混合管理员的角色。

好消息是，这种活动在受害者租户中的多个地方都有记录。

审计日志 在审计日志中，作为Azure AD的一部分，记录了以下活动。

添加/更新策略 "活动类型可以用来确定执行该活动的用户。日志中还有一个IP地址，不幸的是，微软并没有记录实际的源IP，而是记录了他们自己范围内的一个IP地址。

审计日志中的另一个日志条目，"为跨租户访问设置添加伙伴 "是一个非常有价值的活动类型，用于检测和提醒可能的CRS滥用。在 "修改的属性 "下的活动中，你可以看到攻击者租户的租户ID。

有趣的是，没有记录显示租户名称，只有租户ID，即使你用租户名称来配置它。你可以使用跨租户访问设置中的一个小技巧，从租户ID 租户名称进行查询。在跨租户访问设置（链接）中，点击 "添加组织"，输入一个租户ID，Azure会告诉你相关的租户名称。

也许这是一个小红队的提示，但它对所有租户都有效，正如你所看到的:)

当你配置CRS时，它也会给你下面的弹出窗口。

然而，这项活动只记录在GUI中，没有记录在活动日志中。在供应日志中也没有记录。

总结一下，根据审计日志，我们可以检测到跨租户设置，并看到攻击者的租户ID和配置此设置的用户。Azure AD中的其他日志（登录/配置）和活动日志对检测这种情况没有用。

让我们进入下一个步骤。

第2步--对两个租户的自动赎回

还是在受害者租户中，我们启用了用户同步，并抑制了同意提示，所以现在在受害者租户中一切都配置好了。这又导致Azure门户中出现了两个弹出式窗口，而活动日志中没有记录。

我们要在攻击者租户中做同样的事情，在那里我们必须添加受害者租户和设置。我们可以访问攻击者租户进行调查，这并不现实，然而当我们添加一个组织时，我们会看到同样的证据。

第3步 - 确定攻击租户的同步设置

在攻击者租户中，我们配置了一个跨租户的配置，决定了什么被同步。在这一步，我们还将测试攻击者和受害者租户之间的连接。由于这都是在作为响应者的攻击者租户上进行的，所以我们通常无法访问这个。为了完整起见，在审计日志中，作为配置和测试的一部分，创建了以下日志条目。

为了存储与CRS相关的配置细节，将在攻击者租户中创建一个应用程序和一个相关的服务器主体。另一个有趣的发现是，攻击者一方的事件记录了实际的源IP地址，而不是微软的IP地址。

第4步 - 测试

现在我们已经建立了连接，我们将在攻击者租户中创建一个用户，并执行同步，确定我们可以在受害者租户中找到什么证据。我们创建了一个 "test_sync_user_1 "并执行了自动同步。当我们切换到受害者租户Azure AD时，我们可以看到，在用户下，我们现在有一个额外的用户，这是很成功的。

如果我们点击ExternalAzureAD，可以看到源AzureAD（invictusirtraining.onmicrosoft.com）。

让我们深入研究一下审计日志，看看我们是否能确定这一活动的来源。

正如你所看到的，有相当多的事件产生于用户的创建，但我们如何确定这是CRS的结果？

我们可以利用以下细节的组合来确定这是源于CRS的。

B2B和外部Azure AD的存在可以帮助我们确定这来自不同的租户，然而正常的B2B也会产生类似的结果。因此，确定这是一个来自CRS的结果的（唯一）方法是检查CRS初始设置的审计日志。

KQL查询

下面的KQL查询可以用来检测这种类型的攻击，它可以提取源和目标租户以及执行该动作的用户。

审计日志 | where OperationName == "向跨租户访问设置添加伙伴" | where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == "tenantId" | extend initiating_user=parse_json(tostring(InitiatedBy.user)).userPrincipalName | extend source_ip=parse_json(tostring(InitiatedBy.user)).ipAddress |扩展target_tenant=parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue | 项目生成时间,操作名称,启动用户,源_ip,AADTenantId,目标_租户 | 项目-重命名 source_tenant= AADTenantId

结果应该是这样的。

总结

在受害者方面，最重要的日志来源是审计日志，这是唯一记录与CRS相关活动的日志。在审计日志中，"向跨租户访问设置添加伙伴 "的活动表明正在创建CRS。为了确定哪些用户被同步到受害者租户，必须使用活动和和事件类别的组合。