关于 AWS 勒索软件您需要了解的要点

尽管勒索软件在数据中心内是一个相当严重的问题，但我此前一直有些怀疑它在云中是否同样棘手。我个人从未遇到过相关事件，因此我一度认为这更多只是理论上的风险。事实证明我有点想错了。好吧，是完全想错了。它不仅比我以为的更严重，而且在 Amazon Web Services (AWS) 中的攻击模式也与我的预期不同。

在 AWS re:Inforce 大会上，我参加了一场由 Kyle Dickinson、Megan O'Neil 和 Karthik Ram 主持的精彩会议。现场座无虚席，会场管理人员不得不劝退了数十人。本文是对该会议内容的回顾，并结合了我自己关于 AWS 勒索软件的经验与建议。文中若有任何错误和疏漏，责任在我，而非他们。

要点概览：

• 勒索软件攻击者正越来越多地将目标对准 Amazon Web Services (AWS) 环境，通常利用身份访问、存储配置以及跨服务可见性方面的漏洞。
• Amazon S3 存储桶是常见的入侵入口，攻击者利用薄弱的策略或缺乏强制加密的情况，对关键数据进行加密或删除。
• 在云中有效防御勒索软件需要分层策略，包括访问控制、实时监控以及快速响应工作流。
• FireMon 通过持续监控错误配置、大规模实施策略，并提供有助于团队更快响应云端勒索软件威胁的可见性，从而提升数据安全态势。

Amazon AWS 勒索软件是个问题吗

是的。事实证明，AWS 勒索软件比我最初设想的更成问题。真实客户正在受到影响，这并非只是理论上的风险。

Amazon 勒索软件攻击如何运作

我将在下一个问题中介绍初始利用途径，但 Amazon 勒索软件攻击有四种可能的技术手段：

• 攻击者攻陷某个实例（通常通过对用户/管理员进行网络钓鱼，而非总是直接入侵），然后安装恶意软件来加密数据，并扩散到其他可访问的实例。这与数据中心内的勒索软件其实没有区别，因为它不涉及任何云特有的要素。
• 攻击者将数据从 S3 存储桶中复制出去，然后删除原始数据。这是最常见的云原生 Amazon 勒索软件形式。
• 攻击者使用其控制的 KMS 密钥加密 S3 数据。由于多种因素，这种方式更多停留在理论层面而非现实中。直接删除对象/存储桶要比事后对其加密容易得多。
• 攻击者对另一存储服务中的数据做手脚，以锁定/删除数据。我在此表述得较为含糊，因为尚未见到此类情况，而且大多数此类服务都有内部限制和内置的弹性机制，使勒索软件难以得手。

勒索软件最常瞄准 AWS S3 存储桶，攻击者先复制数据，随后将其删除。实例/服务器也可能成为攻击数据中心所用的同类恶意软件的目标。还有少数理论上的攻击方式在实际环境中并不常见。

不过，一种新的 Amazon 勒索软件攻击正日益增多：勒索软件团伙已开始使用 AWS 的客户提供密钥的服务器端加密 (SSE-C) 对数据进行原地加密。这种技术使攻击者能够直接加密您 S3 存储桶中的文件，而无需将其移出，也不会触发标准告警，并且在没有攻击者自定义加密密钥的情况下无法恢复数据。

威胁行为者如何获得访问权限以实施 Amazon Web Services 勒索软件攻击

泄露的凭据。几乎总是静态访问密钥，但也可能是从被攻陷的实例（通过元数据服务）获取的密钥。可以说，几乎所有基于云的安全攻击都是这样得手的。

S3 勒索软件攻击的步骤顺序是怎样的

我将重点讨论 S3 存储桶勒索软件场景，因为这正是我们要关注的云原生形式。

• 攻击者获取凭据。
• 攻击者利用凭据进行侦察，以确定被允许的 API 调用并识别其可访问的资源。
• 攻击者发现自己拥有 S3 写入权限以及用于识别存储桶的列出/读取权限。请注意，攻击者可能没有 List 权限，但可以从其他来源获取存储桶名称，例如 DNS、GitHub 或其他位置。这种情况的可能性要小得多。
• 攻击者将数据复制/移动到另一位置，该位置不一定在 AWS 中。
• 攻击者删除源对象/文件。
• 攻击者上传勒索信（或发送邮件）。

在近期的攻击活动中，攻击者还开始使用 S3 对象生命周期管理策略，将加密后的文件标记为在七天内删除，以加大受害者支付赎金的紧迫感。他们通常会在受影响的目录中留下一个 warning.txt 文件，其中包含比特币钱包地址和唯一的受害者 ID。

由于整个过程是自动化的，凭据泄露后一分钟内攻击便可能启动。

如何检测 Amazon S3 勒索软件

那么，如果您无法跳到 S3 勒索软件防范这一步……

攻击者通常会留下一封带有联系方式的勒索信，方便您向他们支付比特币。但绝大多数人想必希望在此之前就发现问题。让我们梳理一遍 Amazon S3 勒索软件的攻击步骤，看看可以在哪些环节察觉端倪。

首先，您需要对敏感存储桶启用更深入的监控。由于本文篇幅已经超出我的预期，我将略过如何识别和管理这些存储桶的种种细节，转而聚焦于几个值得考虑的关键数据源。出于成本考虑，请勿指望对所有对象都启用这些功能：

• 当然还有 CloudTrail。
• 针对您关注的任何存储桶启用 CloudTrail 数据事件。这会产生额外费用。
• GuardDuty。
• 可选：Security Hub。这是在您所有账户中汇总 GuardDuty 及其他 AWS 安全服务的最佳方式。
• 或许可考虑：S3 服务器访问日志。 如果您已启用 CloudTrail 数据事件，便可获得大部分所需信息。但 S3 日志的创建是免费的（您只需为存储付费），并且能捕获 CloudTrail 可能遗漏的一些事件（例如认证失败）。它们也需要数小时才能显示，因此在实战事件中并不实用。更多内容请阅读本用户指南。

在介绍完监控之后，我们来看看检测流程中的七个步骤：

1. 检测泄露的凭据与侦察活动

检测流程始于由自身或第三方识别出公开披露或被攻陷的 AWS 密钥，以及任何可疑活动。通常是通过扫描 GitHub 等常见代码库实现的。Amazon Web Services曾经发现了我的一个密钥并给我发了邮件。真是失误。

您的账户凭据侦察检测机制在此可以发挥作用。可选方案包括：

• GuardDuty 检测结果，例如凭据外泄。不过，这存在大约 20 分钟的延迟，而且存在规避技术
• GetCallerIdentity API 调用并不总是恶意的，但在生产账户中不应频繁出现
• GetAccountAuthorizationDetails 每次出现都应触发告警
• 来自单个 IAM 实体的多次失败 API 调用

2. 关注 S3 枚举行为

现在我们开始关注表明攻击者正锁定 S3 的 AWS 勒索软件检测项。您可能已经注意到，由于噪声较多，在这些阶段进行早期检测可能比较困难，但请记住，在通过 CI/CD 管理、人为访问受限的生产账户等场景中，这些检测会更为可行。说不定这还会促使您更多地采用云原生模式。

针对 Discovery 事件的 GuardDuty S3 检测结果，视您的账户和组织的设置情况，除了启用 GuardDuty 之外还需额外开启。请筛选 S3 服务上失败的读取和列出类管理事件与数据事件。您或许能够发现攻击者的窥探行为。您可以在 SIEM 中执行此操作，但为此构建 CloudWatch 指标筛选器同样简便。

3. 监控对象读取与复制

在此阶段，您要持续监控，以判断攻击者是否正在读取对象并制作副本。如果攻击者先读取（复制）再删除每个对象，此行为可能与下一阶段交织在一起。

4. 发现大规模删除与勒索信投放

这是“糟糕”的阶段。攻击者不再只是四处查看，而是正在实施攻击并删除已复制的数据。GuardDuty 的 S3 数据外泄/影响类检测结果会开始触发。请记住，触发至少需要 20 分钟，并且视对象数量而定，这可能是一个滞后的指标。如果您使用 CloudTrail Insights，它会针对用于转移数据的大量 Write 事件发出告警。

您可以针对大量删除调用自行构建检测机制。视您的环境和常规活动模式而定，触发阈值可能很低，因而比 GuardDuty 更快触发。您的 SIEM 和 CloudWatch 指标筛选器都是不错的选择。

5. 识别 SSE-C 滥用（静默加密）

监控 PutObject 等 API 调用中突然出现的 SSE-C 标头，这可能表明数据正在使用攻击者的密钥进行加密。由于 AWS 仅记录操作的 HMAC 哈希值，若没有主动监控，常规取证恢复无法实现。

6. 使用诱饵存储桶与 KMS 检测

成熟的组织可以在账户中预置诱饵存储桶/对象，并对任何触及这些存储桶的操作发出告警。虽然这是一种较不常见的攻击模式，但您可以就账户外部使用 KMS 密钥的情况向相关人员发出告警。

7. 升级处理与事件响应

如果您在此阶段才检测到攻击，说明您已经遭到入侵。此时必须立即响应。请联系执法部门，并联系 AWS 客户事件响应团队。

AWS 勒索软件防护：如何保障企业安全

要成功实施一次 AWS 勒索软件攻击，攻击者需要具备三个条件：

• 获取凭证
• 在 S3 中读写的权限
• 删除无法恢复的对象的能力

在防范勒索软件方面，第一层措施是收紧 IAM，然后使用 AWS 内置工具来提升韧性。说起来容易做起来难，以下是一份以 S3 为重点的检查清单，其中我会尽量略去大部分常见的基础性防护措施：

• 完全不允许使用带有静态访问密钥的 IAM 用户。如果无法做到这一点，则务必使用您的工具识别出所有具备 S3 删除权限的用户。
• 对 SSO/联合身份用户强制启用 MFA。始终如此，绝不例外。
• 让管理员在需要执行删除操作时提升切换到另一个 IAM 角色。您甚至可以将读取权限和删除权限完全拆分到不同的角色中。
• 如果某个实例需要访问 S3，请确保将权限尽可能严格地限定为对最小资源集的最少必需 API 调用。
• 除非绝对必要，否则请禁用 SSE-C。这有助于防止静默加密攻击，此类攻击会让您无法访问自己的数据且没有任何恢复途径。
• 使用 VPC 端点访问存储桶，并叠加一条资源策略，仅允许来自源 VPC 的删除操作。这样攻击者就无法在该 VPC 之外使用这些凭证。
• 启用版本控制、AWS Backup 和/或存储桶复制。这些措施都能确保您不会失去对数据的访问权限。当然，除非您的 IAM 策略出现严重失误，让攻击者得以为所欲为。其中一些功能需要在创建存储桶时启用，因此您可能需要执行一次迁移操作才能实现。

您会注意到我跳过了 Block Public Access。这是一项很好的功能，但许多组织难以大规模实施，因为它们需要一些公开存储桶，而且该功能对使用泄露凭证发起的攻击并无帮助。

所有这些都需要投入精力并增加成本，因此我强烈建议一开始先聚焦于真正重要的存储桶。还有一些更高级的策略，尤其适用于运营大型环境的情况，这里无法一一展开，如果您想探讨，欢迎与我联系。

在 Re:Inforce 分论坛中，您对 S3 勒索软件有哪些新认识

我此前并不知道 S3 勒索软件如此常见，也不知道“先复制后删除”是首选的攻击手法。我原以为攻击者会使用 KMS 加密，而现在完全理解为什么那种方式更偏理论、更为罕见。我对这些检测手段和防御措施本就熟悉，但 AWS 的演讲者以非常清晰、可操作的方式将它们串联在一起，做得非常出色。这场演讲确实超出了我的预期。

FireMon 如何帮助企业实现 S3 勒索软件防护

我们有一款新的 IAM 产品正处于 Beta 阶段，用于实现即时权限，即将发布。我们还在 DisruptOps 中提供态势检查和威胁检测能力，用于识别高风险存储桶并针对恶意活动发出告警，例如勒索软件攻击。如果您想了解这些内容，或者只是希望就我在本文中提到的 AWS 选项获得一些一般性建议，欢迎与我联系。

立即预约演示，了解 FireMon 如何帮助您保护企业免受 AWS 勒索软件的侵害。