在微软最近的一篇文章中，他们介绍了最新的安全保护策略以保护用户免受NOBELIUM活动的影响，该活动针对的是技术服务提供商。

早在 5 月，微软就认定有俄罗斯背景的 NOBELIUM 黑客组织要对持续数月的 SolarWinds 网络攻击事件负责，并同企业、政府和执法机构达成了合作，以遏制此类网络攻击的负面影响。早些时候，微软更进一步地剖析了 NOBELIUM 使用的一套更加复杂的恶意软件传送方法。可知其用于造成破坏，并获得“HTML Smuggling”系统的访问权。微软表示，HTML Smuggling 是一种利用合法 HTML5 和 JavaScript 功能、以高度规避安全系统检测的恶意软件传送技术。近年来，这项技术已被越来越多地用于部署网银恶意软件、远程访问木马（RAT）、以及其它有针对性的钓鱼邮件活动。

Microsoft 365 和 Microsoft Azure 中存在多种类型的信任链，包括委派管理权限 (DAP)、Azure 代表管理员 (AOBO)、Microsoft Azure Active Directory (Azure AD) 企业对企业 (B2B) 、多租户 Azure AD 应用程序以及客户用户。其中许多信任链可以授予对 Azure 资源和 Microsoft 365 的高级访问权限，这需要密切监视。

委托管理特权

DAP是一种方法，通过它，服务提供商可以管理Microsoft 365环境，而不需要维护本地身份。DAP 对服务提供商和最终客户都有好处，因为它允许服务提供商使用他们自己的身份和安全策略管理下游租户。

使用DAP的服务提供商可以在Microsoft 365管理中心通过导航到“设置”，然后到“合作伙伴关系”来识别。在合作伙伴关系中，你可以查看与租户建立计费关系的所有服务提供商的列表，以及服务提供商是否分配了任何角色。

将 DAP 识别为下游客户

虽然终端客户无法看到服务提供商租户中所有可以对最终客户租户进行管理更改的用户的列表，但他们可以通过查看 Azure Active Directory 登录日志来查看服务提供商的登录并过滤服务提供商的跨租户访问类型。可以通过单击“下载”导出结果，并利用这些结果进一步针对 Azure 和 Microsoft 365 进行分类。

服务提供商的登录

AzureAOBO

Azure AOBO在本质上类似于DAP，尽管访问的范围仅限于针对个人Azure订阅和资源的Azure资源管理器(ARM)角色分配，以及Azure Key Vault访问策略。Azure AOBO带来了与DAP类似的管理效益。

要全面评估你订阅中的AOBO权限，请确保已授予全局管理员访问权限，后者将评估服务提供商对每个租户中的所有订阅的访问权限。

Azure AOBO访问是在创建订阅时添加的，可以在给定Azure订阅的访问控制(IAM)中看到。

如果你有多个订阅，请考虑运行以下命令来识别服务提供商可能访问资源的订阅:

Get-AzSubscription | % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" | Where-Object {$_.DisplayName -like "Foreign Principal for * in Role 'TenantAdmins' (*)"} | Select DisplayName, Scope | Format-Table}

也可以授予csp直接访问Key Vault的权限。下面的PowerShell命令可以用来识别允许通过AOBO访问的访问策略Key vault:

Get-AzKeyVault | % { $vault = Get-AzKeyVault -VaultName $_.VaultName; if ($vault.AccessPolicies | Where-Object {$_.DisplayName -like "Foreign Principal for '*' in role 'TenantAdmins' (*)"}) { $vault |select VaultName,ResourceId | Format-Table}}

除了上述命令之外，Azure Red Team工具Stormspotter也可以用于大型环境。

从前面的步骤中收集的信息将用于在分类期间进行日志审查。

Azure AD B2B

Azure AD B2B帐户(客户)可用于管理Azure和Microsoft 365资源。这种管理访问方法利用了另一个租户中的个人现有身份，由于对身份控制的限制，Microsoft通常不推荐这种方法。调查人员应注意授予客户访问 Microsoft 365 中资源的多种方式，其中可能包括 Exchange Online 角色和 SharePoint Online 角色。

Azure订阅

为了全面评估你的订阅中的B2B权限，请确保你已授予用户访问权限，这些用户将根据以下指导评估服务提供商对每个租户中所有订阅的访问：提升访问权限以管理所有 Azure 订阅和管理组。

授予 Azure 角色的 Azure AD B2B 身份显示在 Azure 门户的访问控制边栏选项卡中。

在订阅中具有所有者角色的客户用户

可以使用以下命令系统地识别 Azure AD B2B 身份，该命令将生成可用于定位初始分类的身份和资源列表。

Get-AzSubscription | % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" | Where-Object {$_.SignInName -like "*#EXT#@*"} | Select DisplayName, SignInName, Scope | Format-Table}.

Microsoft 365 (Azure AD)

可以在 Azure AD 特权身份管理边栏选项卡的分配边栏选项卡中查看已在 Azure AD 中授予角色的 Azure AD B2B 身份。过滤“#EXT#”将允许你查看分配给管理角色的所有访客用户。

过滤客户用户

下面的PowerShell还可以用于识别具有管理角色的客户帐户。这些身份信息将用于帮助目标分类。

Get-AzureADDirectoryRole | Get-AzureADDirectoryRoleMember | Where-Object {$_.UserPrincipalName -like "*#EXT#@*"}.

调查信任链

在Microsoft 365和Microsoft Azure中，通过信任链的活动可以看到多个活动，包括Azure AD审计日志、Azure activity日志、Intune审计日志和统一审计日志。使用在“识别”阶段收集的数据，可以执行有针对性的日志检查，以识别信任链滥用。应审查每个日志的来自信任链的活动，特别是重点关注促进持久性、数据收集和侦察的活动。

Azure AD

攻击者通常会使用各种方法来建立持久性，这些方法包括创建新的服务主体、向现有应用程序注册中添加新的秘密、服务主体、创建新的特权用户以及接管现有的特权帐户。你可以通过查看 Azure AD 审核日志并筛选在“识别”阶段识别为最近登录的用户，来识别通过信任链对 Azure AD 所做的修改，比如：

密码重置；

修改服务主体；

将用户添加到特权角色；

对多因素身份验证(MFA)的更改；

创建新用户；

统一审计日志

统一审核日志可用于识别通过 SharePoint Online、Exchange Online、Azure AD 和其他 Microsoft 365 产品中的信任链执行的活动。

统一审核日志从 Azure AD 和 Office 365 中提取数据并将这些数据保留至少 90 天，使其成为非常有价值的集中信息来源，。如果应用 E5 许可证，此数据将保留 1 年，使用高级审计的最长可配置保留期为 10 年。

Search-UnifiedAuditLog cmdlet 可用于搜索在“识别”阶段识别的用户执行的操作。或者，可以使用 Microsoft 365 Defender 门户中的 GUI 搜索日志。

Azure活动

攻击者对Azure资源的访问使他们能够窃取数据并横向移动到连接到目标Azure环境的其他环境。有权访问订阅的攻击者可以部署新资源、通过虚拟机扩展访问现有资源，或者直接从 Azure 订阅中窃取数据和密钥。对Azure资源的访问和操作可以通过检查每个订阅中存在的Azure Activity日志进行审计。

微软终端管理器

攻击者可能通过各种信任链访问Microsoft终端管理器，由于Microsoft终端管理器管理设备的配置，因此它是另一个需要查看的重要审核日志。可以在微软终端管理器门户的租户管理边栏选项卡下访问微软终端管理器审核日志。在审计日志中，启动器“Partner”可用于过滤由Partner发起的操作。在“身份识别”阶段被识别为具有特权的客户用户所采取的操作将需要通过用户主体名称进行搜索。应该检查这些日志事件，以确保没有通过识别的信任链发生恶意活动。

缓解措施

如果在调查过程中发现并确认恶意活动或发现不需要的和过度放任的信任链，则应采取果断措施阻止或最小化访问。根据信任链的类型，可能需要采取不同的步骤来阻止访问。在任何正在进行的调查结束之前，不建议完全删除工件；删除某些工件可能会延迟或增加完成调查的难度。客户应该与他们的服务提供商交流以了解他们有哪些保护措施，并且在发生潜在恶意活动时，通知他们的服务提供商以获得他们在活动验证方面的帮助。

委托管理权限

如果服务提供商对租户的日常活动管理不需要DAP，则应该删除它。在某些情况下，需要权限以方便服务提供商的管理。在这些情况下，微软将引入细粒度的委派管理员权限 (GDAP)，这将允许合作伙伴控制对其客户工作负载的更细粒度和有时间限制的访问。

微软建议服务提供商利用客户租户中的命名帐户来降低风险。如果存在来自服务提供商关系的攻击证据，建议至少在调查结束之前从关系中删除被委派的管理员权限。

要删除委托的管理员权限，请在Microsoft 365管理中心导航到“设置”，然后到“合作伙伴关系”。在伙伴关系中，点击该关系，然后在详细信息选项中选择“删除角色”。采取此操作将阻止服务提供商以全局管理员或帮助台管理员的身份访问租户。删除此访问权限不会更改或更改当前通过服务提供商购买的计费关系或许可证。

AzureAOBO

如果 Azure 订阅的有效日常管理不需要 Azure AOBO 访问权限，则应删除它。如果服务提供商需要访问 Azure 订阅，则应该通过添加具有适当角色和权限的外部主体来应用最小权限。如果有证据表明来自服务提供商的攻击，那么应该从每个Azure订阅中删除外部主体。

可以利用 Azure 策略 监控通过 AOBO 授予的权限。你可以在Tenant Root Group部署Azure 策略，如果将外部主体的权限分配给Azure中的资源，则该策略将引发不合规。虽然Azure 策略不能阻止使用外国主体创建订阅，但它简化了关于订阅存在的报告，并允许在需要时自动删除或阻止创建。

可以通过导航到受影响订阅上的访问控制 (IAM) 边栏选项卡，为服务提供商选择外部主体，然后删除 Azure AOBO 权限

删除外部主体的 Azure AOBO 权限

安全检测

日志记录的集中可用性对于响应和调查潜在事件至关重要，并且是此类 DART 调查的首要障碍。如果组织正在监控其云环境的特权访问和管理更改，则应该可以发现并警告涉及授权管理特权滥用的恶意活动。

应将云活动日志提取到安全信息和事件管理器 (SIEM) 中并保留以供分析。包括：

Office 365 统一审核日志；

Azure AD 管理员审核日志和登录日志；

Microsoft终端管理器审计日志。

可以利用Azure活动日志和特定的数据平面日志(如Azure Key Vault和Storage Azure 策略)来强制执行一致的日志标准。

作为事件响应者，当有数量和质量都丰富的可用数据时，DART 最有效。一种感兴趣的日志类型是登录日志；身份事件可以告诉我们很多关于攻击活动的信息。通常可以在这些日志中识别模式，这些模式可以像 IP 地址匹配一样简单，也可以像 UserAgent 字符串、时间和应用程序 ID 匹配一样复杂。

话虽如此，最关键的日志记录是管理活动的日志记录。管理帐户的任何使用或执行的操作都非常重要，应受到监控，在企业环境中，大多数更改通常是在批准的更改窗口期间进行的，应评估此范围之外的更改的有效性和完整性。

日志本身是很有用的，但对于及时显示不寻常或恶意活动，警报是至关重要的。Microsoft 365 Defender 门户有一些有用的内置警报来识别可疑活动。比如：

提升Exchange管理权限；

启动或导出eDiscovery搜索；

创建转发或重定向规则；

还可以创建自定义警报以提醒其他类型的活动，另一个比较好用的警报工具是 Microsoft Defender for Cloud Apps（以前称为 Microsoft Cloud App Security）。此工具可以从 Azure AD、Office 365、Azure、Defender for Endpoint、Defender for Identity 以及许多第三方服务中提取数据。策略引擎可用于基于内置模板或自定义定义创建警报策略。以下是一些模板化策略的例子：

来自非公司IP地址的管理活动；

可疑的管理活动；

向OAuth应用程序添加可疑凭证；

可疑的OAuth应用程序文件下载活动；

多个虚拟机创建活动；

微软安全建议

微软建议客户定期与服务提供商进行交流，以了解为访问其租户设置的安全控制。应该密切监视服务提供商对资源的访问，如果一段时间未使用，则应按照严格的最低权限流程进行删除。

保护管理访问的一些具体方法包括使用即时管理解决方案，例如特权身份管理，包括定期审查管理员以确保仍然需要他们的访问。MFA 也很关键，不仅是启用 MFA，还要确保所有管理员都注册了 MFA 方法。

本文翻译自：https://www.microsoft.com/security/blog/2021/11/22/how-to-investigate-service-provider-trust-chains-in-the-cloud/如若转载，请注明原文地址