译者：知道创宇404实验室翻译组
原文链接：https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/

这篇文章包含近期国家网络攻击背后攻击者的技术细节。以下是攻击者常使用的工具及技术：

• 通过SolarWinds Orion产品中的恶意代码入侵。这导致攻击者在网络中获得立足点，从而获得更高的凭据。详请参阅SolarWinds安全咨询。
• 一旦进入网络，攻击者就会使用通过本地泄露获得的管理权限来访问组织的全局管理员帐户/可信的SAML令牌签名证书。这使得攻击者能够伪造SAML令牌，以模拟任何现有用户和帐户，包括高权限帐户。
• 然后，可以针对任何本地资源（无论身份系统或供应商如何）以及任何云环境（无论供应商如何）使用由受损令牌签名证书创建的SAML令牌进行异常登录。因为SAML令牌是用它们自己的可信证书签名的，所以组织可能会忽略异常。
• 使用全局管理员帐户/可信证书来模拟高权限帐户，攻击者可以向现有应用程序或服务主体添加自己的凭据，使它们能够使用分配给该应用程序的权限调用API。

活动描述

初始访问

尽管我们不知道后门代码是如何将其添加到库中的，但从最近的活动来看，攻击者可能已经破坏了SolarWinds的内部构建或分发系统，将后门代码嵌入到一个合法的SolarWinds库中，文件名为SolarWinds.Orion.Core.BusinessLayer.dll。自2020年3月以来，可以通过目标网络中的自动更新平台或系统来分发此后门。

执行

在更新SolarWinds应用程序时，嵌入的后门代码在合法代码执行之前加载。系统会误没有发生恶意活动，并且依赖于库的程序的行为符合预期。

攻击者已经破坏了使用目标公司自己的数字证书的签名库，试图逃避应用程序控制技术。Microsoft已经从其受信任列表中删除了这些证书。带有签名哈希的证书详细信息如下所示：

然后从SolarWinds应用程序的安装文件夹加载DLL。主植入程序将作为Windows服务和DLL文件安装在以下路径中，使用具有不同名称的文件夹：

• 例如，SolarWinds Orion安装文件夹：%PROGRAMFILES%\SolarWinds\Orion\SolarWinds.Orion.Core.BusinessLayer.dll
• .NET程序集缓存文件夹（编译时）：%WINDIR%\System32\config\systemprofile\AppData\Local\assembly\tmp\<VARIES>\SolarWinds.Orion.Core.BusinessLayer.dll

安全研究人员发现，只有在运行SolarWinds.BusinessLayerHost.exe时，攻击者才会激活恶意代码。

命令与控制（C2）

恶意DLL使用avsvmcloud.com域调用远程网络基础结构。准备可能的第二阶段有效负载，在组织中横向移动，破坏或过滤数据。

微软将主要植入程序及其组件检测为Solorigate。

目标行动

在微软云上观察到的行为中，攻击者要么使用泄露的特权帐户凭证（例如被盗的密码）获得管理权限，要么通过使用泄露的SAML令牌签名证书伪造SAML令牌。

即使我们看到SAML令牌签名证书泄露，但有些情况下，攻击者获得证书访问权的具体机制还是不确定。我们可以使用常用工具访问支持SAML联合服务器的数据库，并使用管理访问和远程执行功能。

在一些情况下，服务帐户凭据已被授予管理特权。而在另一些情况下，管理帐户可能已被不相关的机制破坏。通常，证书存储在提供SAML联合功能的服务器上。这使得在该服务器上具有管理权限的任何人都可以从存储或读取内存访问它。

一旦获得了证书，攻击者就可以使用他们选择的任何声明和生存期来伪造SAML令牌，然后用获得的证书对其进行签名。这样，它们可以访问任何配置为信任使用该SAML令牌签名证书签名的令牌的资源。这包括伪造一个声称代表Azure AD中的高特权帐户的令牌。

与内部部署帐户一样，攻击者还可以通过泄露的凭据获得管理Azure AD权限。如果有问题的帐户没有受到多因素身份验证的保护，这种情况就很有可能发生。

不管攻击者是铸造SAML令牌还是通过其他方式获得对Azure AD的访问权，都会观察到使用这些管理权限的特定恶意活动，包括以下所述的长期访问和数据访问。

长期访问

攻击者在本地环境中获得了立足点，因此对Azure Active Directory设置进行了修改，以进行长期访问。

1.Federation Trusts：

• 攻击者向现有租户添加新的联合身份验证信任，或修改现有联合身份验证信任的属性以接受使用攻击者拥有的证书签名的令牌。

2.OAuth应用程序和服务主体凭据：

• 攻击者向一个或多个合法的OAuth应用程序或服务主体添加凭据（x509密钥或密码凭据），通常具有现有的Mail.Read或Mail.ReadWrite权限，从而可以通过Microsoft或Outlook REST从Exchange Online读取邮件内容。
• 攻击者可以使用他们的管理员特权向目标应用程序或服务主体授予额外的权限（例如：Mail.Read，Mail.ReadWrite）。

数据访问

数据访问依赖于利用生成的SAML令牌来访问用户文件/电子邮件，或者通过使用添加的凭据来验证和获取访问令牌来模拟应用程序或服务主体。攻击者定期从VPS提供商的服务器连接，以使用授予模拟应用程序或服务主体的权限访问特定用户的电子邮件。在许多情况下，目标用户是重要的IT和安全人员。通过模拟使用Mail.Read等权限的现有应用程序来调用攻击者使用的相同API，访问将被隐藏在正常流量中。

建议

如果您没有受到攻击者的危害，建议您考虑以下操作来避免攻击：

• 运行最新的防病毒或EDR产品，检测受损的SolarWinds库以及这些二进制文件可能出现的异常进程行为。更多细节请咨询SolarWinds的安全顾问。
• 使用您的网络基础设施阻止IOCs中列出的已知C2端点。
• 请遵循身份联合技术提供商的最佳方法来保护您的SAML令牌签名密钥。对于Active Directory联合身份验证服务，请在此处查看建议：保护ADFS的最佳实践。
• 确保具有管理权限的用户遵循最佳做法，包括使用特权访问工作站、JIT/JEA和强身份验证。减少高权限目录角色（如全局管理员、应用程序管理员和云应用程序管理员）的用户数。
• 确保具有管理权限的服务帐户和服务主体使用安全存储的媒介（如证书）。
• 通过删除/禁用未使用或不必要的应用程序和服务主体来减少易受攻击的面积。减少对活动应用程序和服务主体的权限，尤其是应用程序（AppOnly）权限。
• 有关更多建议，请参阅保护Azure AD标识基础结构。

对于没有Azure Sentinel的客户，可以使用相同的检测逻辑来搜索统一审核日志（UAL）：

• 异常的Azure Active Directory PowerShell行为
• 修改的域联合身份验证设置
• 添加到OAuth应用程序或服务主体的新访问凭据

IOCs

命令与控制

SolarWinds.Orion.Core.BusinessLayer.dll的恶意实例

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1427/