到目前为止，我们都应该从与此已知威胁相关的不断新闻文章中了解勒索软件。正如我们在云攻击剖析中所解释的那样，勒索软件是攻击者通过数据加密控制您的帐户从而限制您对系统的访问来赚钱的一种方式。

本文将介绍我们可以减轻攻击者用来在 Azure 环境中传播勒索软件的方法。

Azure 威胁研究矩阵

如果熟悉Azure 威胁研究矩阵（MITRE ATT&CK 框架的替代方案），Microsoft 不再将“初始访问”视为 Azure 威胁检测生命周期的第一点。

Azure 威胁检测矩阵从侦察层开始，我们需要关注的地方。这是渗透测试活动中的经典方法。攻击者试图被动或主动地获取尽可能多的信息（即，IP 发现或可公开访问的资源的端口扫描）。

从云中暴露的角度来看，攻击者可以通过多种方式获得访问权限。

可能存在受损的用户帐户。
流氓用户可能已经离开了具有现有完全或共享权限的组织。
您的面向公众的应用程序或服务中可能存在简单的错误配置。
一段配置不正确的代码可能会在您的应用程序中造成漏洞。

勒索软件是云中威胁检测一系列失败的结果。这不是您遇到的最初问题，因此有必要评估和检测每种技术以防止此类攻击。在这种情况下，它是 Azure 上的勒索软件。

我们需要应用一系列 Azure 最佳实践来在运行时以及应用程序生命周期管道中更早地实现异常行为检测。我们需要通过CI/CD管道图像扫描确保我们的基础设施即代码 (IaC)模板中不存在错误配置，并构建护栏，例如基于每个用户提供的有限信任用户凭据。我们将尝试在下面解决这些最佳实践中的每一个。

在我们开始研究 Azure 威胁检测工具（例如Microsoft Defender和Azure Sentinel）之前，建立良好的卫生习惯很重要。
- 确保用户拥有唯一的凭据（不是凭据共享）。
- 强制执行多重身份验证(MFA)。
- 遵循最小权限原则限制用户权限。
- 限制允许哪些连接进出我们的 Azure 环境。
  
  让我们浏览一下 Azure 的威胁检测矩阵。

侦察

Nmap、Metasploit、SQLMap和许多其他工具不具备在 Azure 基础架构级别进行扫描的任何实际功能。ScoutSuite或aws-extended-cli等其他工具专注于云环境，可以帮助您进行安全态势评估。

Azure 上的勒索软件

那么他们究竟如何找出哪些主机正在运行面向公众的应用程序，或者他们如何识别现有漏洞？

IP发现

公共 IP 地址允许 Internet 资源与 Azure 资源进行入站通信。通过查看虚拟网络接口可以很容易地查看资源上的 IP 地址。
只需在 Azure CLI 中运行*az network public-ip show 。*

公共 IP 地址是使用 Microsoft Azure 中的某些定价单位 (SKU) 创建的。在“基本”产品下，公共 IP 地址安全性默认处于打开状态。建议使用网络安全组(NSG)，但可以选择使用它来限制入站或出站流量。未能配置这些 NSG 会向计划传播勒索软件的潜在对手开放我们的集群。

Azure 中的 NSG 是激活规则或访问控制列表 (ACL) 的标准化方法，它将允许或拒绝到虚拟网络中的虚拟机实例的网络流量。NSG 可以与子网或该子网中的单个虚拟机实例相关联。

标准 SKU 提供“默认安全”模型，这意味着它在用作前端时应该对入站流量关闭。这是一项改进，但我们必须考虑允许我们的应用程序运行所需的入站/出站流量的“最小特权”概念，并限制通过 NSG 的所有其他流量。

端口映射

可以通过查看虚拟网络接口分配的 NSG 来查看虚拟机上的开放端口。这是一个类似的过程，因为我们可以从 Azure CLI运行“ az network nsg show ”。

当我们考虑主机节点的虚拟 IP 时，通过虚拟主机 IP 地址 168.63.129.16 和 169.254.169.254 提供基本的基础设施服务，如 DHCP、DNS、IMDS 和健康监控。这些 IP 地址是唯一在所有区域中使用的虚拟化 IP 地址。事实上，AWS、GCP 和 Azure 正在使用链接本地地址“169.254.169.254”。

默认情况下，这些服务不受已配置的 NSG 的约束，除非每个服务特定的服务标签作为目标。要覆盖此基本基础结构通信，您可以通过在 NSG 规则中使用以下服务标记来创建安全规则以拒绝流量：

Azure 平台 DNS
Azure 平台 IMDS
Azure平台LKM

NSG 规则的属性如下所示：

我们还需要通过限制特定端口在主机虚拟机 (VM) 上打开的正常运行时间（总时间）来减少与攻击相关的风险。实际上，在端口扫描攻击的情况下，我们只需要端口保持打开的时间很短——就足以完成我们的基本维护任务。即时 VM 访问可用于限制这些端口在 Azure VM 上保持打开状态的时间。

它利用 NSG 规则来实施安全配置和访问模式。

初始访问

最常见的攻击方法之一是通过远程桌面协议 (RDP) 访问 Windows 主机，或通过安全外壳 (SSH) 协议访问 Linux 系统。

Azure 上的勒索软件

尽管两者在远程访问主机端点的方式上有相似之处，但它们之间存在一些明显的设计差异。在设计方面，SSH 不需要额外的工具，例如虚拟专用网络 (VPN) 或多因素身份验证 (MFA) 来访问它们，而 RDP 则需要两者。在任何一种情况下，这些访问方法的主要问题是它们基于您管理凭据的方式、您公开端点的方式以及您可以添加多少安全层，即使它会影响用户体验。

有效凭证

如上所述，对手或心怀不满的前雇员可能能够使用有效凭据从组织外部登录到 Azure AD。通过使用有效凭据登录帐户或服务主体，对手将获得该帐户或服务主体的所有特权。如果帐户具有特权，这可能会导致其他策略，例如持久性或特权升级。

Active Directory 协议广为人知。还值得注意的是，它仍然是勒索软件攻击的主要目标。随着对安全性和更好的数据管理的需求不断增加，组织继续转向 Azure AD 等高级云应用程序，但仍存在一些值得关注的差距。

防止对 RDP 实例的暴力攻击

为了保护您的 RDP 实例，我们强烈建议配置帐户锁定阈值。如果没有配置阈值，攻击者可以“暴力破解”实例，直到他们成功接管帐户。攻击者实际上需要使用一种自动化工具来连续提交许多密码，直到“猜到”正确的密码。这对于单个用户来说是不可能的。

将失败的登录尝试设置为阈值，如 10 分钟内尝试 10 次，应该可以防止这种攻击向量起作用。Microsoft Azure 在 Azure AD 中本地实施了一个名为身份保护的工具，该工具旨在识别围绕身份验证事件的潜在风险行为。拥有 Azure AD Premium P2 许可证的用户可以按照补救步骤检查可疑活动并采取措施防止恶意帐户接管。

针对单点登录 (SSO) 的密码喷洒攻击

密码喷洒是一种蛮力攻击。在此攻击中，不良行为者将根据应用程序上具有默认密码的用户名列表进行暴力登录。

例如，攻击者将对应用程序上的许多不同帐户使用一个密码（例如Sysdig@123 ），以避免通常在使用多个密码强制使用单个帐户时发生的帐户锁定。

对于 SSO 用户，他们无需输入密码即可自动登录 Azure AD。这很好，因为它可以避免手动重复使用弱密码。但是，用于 SSO 的协议存在缺陷，因为它允许攻击者执行单因素暴力攻击。尽管此缺陷不仅限于 SSO，因此您的密码需要足够安全。

Microsoft 强调在登录时使用多因素身份验证 (MFA) 作为替代的高级威胁防御解决方案。虽然 MFA 不能完全阻止密码泄露，但它是一个很好的起点。例如，在部署 MFA 时，公司支持提供商无法通过 Remote PowerShell (RPS) 联系。因此，员工通常会求助于通过在 Office 365 中创建的管理员帐户轻松访问。这些帐户正是坏人所寻找的；他们没有 MFA 安全性。

执行

Microsoft 构建其 Azure AD 解决方案的方式可以防止坏人横向移动或窃取我们的数据。

Azure 上的勒索软件

这很好，因为攻击者想进入云帐户内部，寻找数据所在的位置，以便在 Azure 平台上成功勒索。

Microsoft 确保使用其默认安全解决方案在 Azure AD 中实施精细的安全控制，但是，攻击路径具有 Microsoft AD 设计中不存在的弱点。

组织单位 (OU) 缺乏支持

与 AD 不同，Azure AD 不支持组织单位。通过组管理用户和设备是监控大型组织内访问的最简单方法。因此，缺乏 OU 支持会给 IT 团队带来更大的管理负担。IT 团队经常忽视冗余活动，安全性受到损害。

组策略对象 (GPO) 缺乏支持

还值得注意的是，对我们连接到网络的设备的控制较少。与传统的 Microsoft AD 不同，Azure AD 也不支持组策略。它们帮助管理员管理网络上的所有设备。如果没有 GPO，管理大型组织的设备设置几乎是不可能的。

下载恶意软件后，它会扫描本地和网络系统以查找要加密的文件。如果没有组策略，我们可能会遇到横向移动攻击，例如具有有限网络控制的勒索软件来阻止这种移动。

如果没有泄露的凭据，简单地登录可能是网络攻击者找到进入目标组织并投放恶意负载的最简单方法。接下来，我们将看看这些特权升级尝试是如何发生的。

权限提升

Azure 上的勒索软件

如果对手的当前帐户有资格通过特权身份管理 (PIM) 激活角色，则对手可能会提升他们的特权。PIM 服务专为 Azure AD 而设计，它使你能够管理、控制和监视对组织中重要资源的访问。同样值得研究的是我们如何使用基于角色的访问控制 (RBAC) 来防止访问特定服务和在这些服务中进行权限升级。

特权身份管理 (PIM)

通过最大限度地减少有权访问安全信息或资源的人数，我们最终减少了恶意行为者首先访问我们环境的机会，并防止授权用户无意中影响 MS Azure 的敏感资源.

PIM 用作 Azure AD 的一种特权访问管理 (PAM) 解决方案。它提供特权用户活动、会话记录、频繁更改密码等的完整审计跟踪。PIM 为指定用户提供超出标准用户所拥有的特殊访问权限，因此需要保护特权帐户的滥用。

基于角色的访问控制 (RBAC)

Azure RBAC 是用于管理对 Azure 特定资源的访问的授权系统。例如，在 Azure AD 中，RBAC 用户有权访问其角色所需的特定应用程序/服务。例如，SQL DBA 不一定需要访问 Azure Kubernetes 服务 (AKS)，当然也不需要完全访问权限来在 AKS 中创建或删除集群。如果攻击者获得该用户帐户的访问权限，创建不同的角色帐户将对攻击者的爆炸半径产生明显影响。

Azure 上的勒索软件

以下是 Azure AD 中的四个常见角色，以更好地理解它的工作原理：

只读访问角色
对于希望实现“有限信任”权限的团队，这是强烈推荐的用户访问控制。尽管攻击者在破坏 Azure AD 中的此角色时可以访问敏感信息，但仅限于基本的只读特定操作。
不良行为者现在没有提升的权限来在 Azure 中进行更改。他们可以通过 vNet 跟踪新目标和地址空间，但他们无法提升应用程序的权限，这可以通过所有者访问角色来实现。
所有者访问角色
此角色应该很少使用。在这种情况下，所有者有权编辑资源并授予对任何资源的权限。因此，对于希望授予自己对 Microsoft Azure 中其他服务的权限/访问权限的威胁参与者，此角色非常感兴趣。这是 Azure 上勒索软件的最坏情况。
贡献者角色
此角色不允许向其他用户授予访问权限。它专为管理 Azure AD 资源而设计。帮助台团队可以在其有限状态下使用此角色，以允许上传新文件夹和文件。担任此角色的用户无法删除、移动或复制文件，这意味着他们将确保围绕“零信任”的合规性，同时防止可能因最终用户错误导致的数据丢失。
```
  az role assignment create --assignee "nigeldouglas@azure.com" \
  --role "Reader" \
  --resource-group "technical-marketing"
```

权限维持

Azure 上的勒索软件

假设攻击者已经通过前面提到的一种技术（如暴力/密码喷射攻击）获得了访问权限并设法提升了他们的权限，那么攻击者现在可以修改 NSG 中的规则以建立对其他端口的访问权限，并执行他们的横向移动。

适用于云的 Microsoft Defender 提供高质量的威胁检测和响应功能，也称为扩展检测和响应 (XDR)。除了使用Microsoft Defender for Cloud监控密码喷洒等暴力尝试外，它还可用于监控禁用安全性的对手，因为这通常是人为操作的勒索软件(HumOR) 攻击链的一部分。

在传统的本地环境中，隔离端点以防止磁盘加密非常重要。端点隔离本质上意味着将有风险的计算机或其他端点设备与网络的其余部分隔离开来。隔离后，安全团队可以主动消除威胁，并运行补救和调查流程。一旦所有的安全问题都得到解决，我们就可以继续将受感染的端点重新添加到网络中，以减少横向移动或当受感染的设备留在网络上时可能发生的任何形式的数据泄露。

由于云 VM 可以很容易地启动和拆除，从持久性的角度来看，这不是我们最关心的问题。相反，我们需要优先考虑对手会尝试防御规避（例如事件日志清除）的场景，尤其是在他们希望破坏入侵检测和事件响应取证所需的安全事件日志和 PowerShell 操作日志的情况下。

禁用安全控制

如前面提权中所述，攻击者还可能试图禁用与某些特定 NSG 关联的安全工具/控件，从而逃避检测。

一般来说，Azure Defender 的反恶意软件保护应该自动保护端点、电子邮件服务器和网络，因为它旨在缓解已知的勒索软件。然而，在某些情况下，较新的勒索软件变体能够绕过此类保护并成功感染目标系统。

在 Linux 中，如果启用了设置用户 ID (SUID) 和设置组 ID (SGID) 位，则非根用户可以使用某些二进制文件和命令来提升根访问权限。有大量的可执行命令可以允许权限提升。

GTFOBins是一个精选的 Unix 二进制文件列表，可用于绕过错误配置系统中的本地安全限制。

- rule: Set Setuid or Setgid bit
  desc: >
    When the setuid or setgid bits are set for an application,
    this means that the application will run with the privileges of the owning user or group respectively.
    Detect setuid or setgid bits set via chmod
  condition: >
    consider_all_chmods and chmod and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")
    and not proc.name in (user_known_chmod_applications)
    and not exe_running_docker_save
    and not user_known_set_setuid_or_setgid_bit_conditions
  output: >
    Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name
    command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
  Priority:
    NOTICE
  tags: [process, mitre_persistence]

这种行为存在于文件和目录中。通过更改文件或目录中的 SUID 和 SGID 位，其他用户可以使用文件所有者（即 root）的相同访问权限运行它们，从而使普通用户能够编辑系统拥有的密码文件行政。

因此，我们实施良好的用户访问卫生至关重要，包括 MFA、强密码、有限信任规则和 Falco 等其他取证工具，以识别用户执行不寻常的强制登录尝试或试图提升权限的情况。

目标是尽早阻止这些行为，以免它们升级并最终导致 Azure 上出现勒索软件。

通过 Rootkit 传播勒索软件

Rootkit 是为获得对目标计算机的访问权而创建的恶意计算机软件的集合，通常会隐藏其存在或其他软件的存在。rootkit 一词是“root”（类 Unix 操作系统上的特权帐户）和“kit”（指实现该工具的软件组件）的组合。

许多用户可能已经熟悉使用开源 Falco 来检测以 root 身份运行工作负载或服务的尝试。但是，我们最好在此博客中关注更多特定于勒索软件的行为。在许多情况下，rootkit 会在 /dev 目录中写入非设备文件以逃避检测并确保持久性。

建立 Falco 规则来检测这种行为真的很有帮助：

- rule: create_files_below_dev
  desc: creating any files below /dev other than known programs that manage devices. Some rootkits hide files in /dev.
  condition: (evt.type = creat or evt.arg.flags contains O_CREAT) and proc.name != blkid and fd.directory = /dev and fd.name != /dev/null
  output: "File created below /dev by untrusted program (user=%user.name command=%proc.cmdline file=%fd.name)"
  priority: WARNING

渗透

对手将试图通过将敏感的公司数据发送到命令与控制 (C2) 服务器来泄露/窃取敏感的公司数据。

Azure 上的勒索软件

如果我们阻止连接到那些与列入黑名单的 C2 服务器相关的已知不良 IP/域名，我们就可以防止专门针对这些目的地的数据丢失。

威胁源

Falco 是一个开源解决方案，可用于检测与那些已知恶意 IP 的异常出站连接。要完成此步骤，我们会将此规则写入/etc/falco/malicious_ips_rule.yaml下的文件。

在以下命令中，我们将 cURL 用于出现在超过五个来源中的压缩 IP 列表，并从中生成 Falco 列表宏。您可以使用任何提要。这是我们使用的一个名为FeodoTracker的免费示例，它由Abuse.ch的安全分析师维护。

我们会将生成的 Falco 列表保存到名为malicous_ips_list.yaml的文件中。

curl --compressed https://feodotracker.abuse.ch/downloads/ipblocklist.txt 
2>/dev/null | grep -v "#" | grep -v -E "s[1-5]$" |  cut -f 1  | sed "s/.*/'"&"',/g" 
| tr 'n' ' ' | sed "s/, $//" | sed 's/.*/- list: malicous_ip_list'

Once we have written the malicious IP list to ‘<strong>malicous_ips_list.yaml</strong>,’ we can create a Falco rule that detects connections to/from the list of IP addresses provided.

– rule: Malicious IPs
 desc: Detect connections to/from a malicious IP
 condition: (inbound_outbound) and fd.sip in (malicous_ip_list) or fd.cip in (malicious_ip_list)   
 output: >
   Suspicious connection to/from a malicious IP detected (command=%proc.cmdline connection=%fd.name user=%user.name container_id=%container.id)
 priority: WARNING
 tags: [network]

网络策略

我们讨论了在基础设施级别使用 NSG。尽管很重要，但重要的是将相同的零信任概念应用于AKS等 Azure 服务。

在 Kubernetes 中，您可以使用默认拒绝策略来丢弃以前策略中未明确允许的所有流量。这样，无论流量是否被威胁源明确标记和丢弃，我们都应该丢弃所有多余的流量。这是一个很好的实践，也应该应用于核供应国集团。

以下是 NetworkPolicies 的示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
Metadata:
  name: default-deny-all
Spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

敏感用户数据的备份

勒索软件攻击是故意设计的，目的是加密或破坏敏感数据和/或系统。如果数据对最终用户没有价值，企业就没有动力支付赎金释放费。

除了将敏感数据泄露到第三方 C2 服务器外，攻击者还会以备份您的数据为目标，以确保通过支付赎金检索敏感数据。如果备份被加密或销毁，则组织没有数据副本。

Azure 备份在数据传输和静止时为备份环境提供安全性。
在这种情况下，备份存储在 Azure 存储中，因此攻击者无法直接访问敏感的备份存储。与 VM 类似，Azure 在名为Azure fabric的服务中创建存储的备份快照，其中来宾或攻击者除了为应用程序一致的备份停止工作负载外没有任何参与。

az backup protection backup-now \
    --resource-group testRG \
    --vault-name testRecoveryServicesVault \
    --container-name nigelsVM \
    --item-name nigelsVM \
    --backup-management-type AzureIaaSVM
    --retain-until 11-12-2022

示例：备份虚拟机“nigelsVM”并将恢复点的到期时间设置为 2022 年 12 月 11 日

在上述所有步骤都失败的情况下，备份管理应被视为最后一道保护线。假设一个组织受到勒索软件攻击，在初始攻击之前确定要保护的最关键系统并在整个杀伤链中应用最佳实践将帮助企业响应事件并快速回滚到事件发生之前的快照。

备份管理不会阻止，但会减轻勒索软件 Azure 攻击对你的组织的影响。事实上，CISA 建议个人和企业使用所谓的 3-2-1 策略来备份敏感数据。

以下是 3-2-1 备份规则涉及的内容：

3 – 保留任何重要文件的三份副本：一份主要文件和两份备份文件。
2 – 将文件保存在两种不同的媒体类型上，以防止不同类型的危害。
1 – 在异地存储一个副本（例如，不应驻留在可能受感染的云环境中）。

结论

组织可以通过应用最小权限原则来防止（在大多数情况下）初始访问以及横向移动。最小权限原则基于这样的假设，即每个人、每个设备、每个应用程序等都是对组织的潜在威胁，因此应该只授予他们完成特定工作职能所需的访问权限。

最小权限可以应用于我们扫描并允许进入集群的图像、我们通过 NetworkPolicies 允许/拒绝的网络流量，以及我们通过 NSG 建立/阻止的连接。实施上述最小特权原则听起来可能很简单，但您确实需要确保您的团队通过为以下方面分配明确的责任归属来积极管理 Azure 环境的安全状况：

监控安全态势
减轻资产风险

通过自动化和简化这些任务，您可以提高在 Azure 威胁研究矩阵的各个阶段防止 Azure 勒索软件攻击的能力。手动执行这些任务会增加最终用户错误的风险，无法适应组织变化，并且如果新管理员将来必须接管您的角色，最终无法顺利转移。

原文链接：https://sysdig.com/blog/ransomware-azure-mitigations/