Sysdig 威胁研究团队最近在客户环境中发现了一起导致专有数据被盗的复杂云活动：SCARLETEEL。攻击者利用容器化的工作负载将特权升级到 AWS 帐户，以便盗取专有软件和凭据。他们还企图使用 Terraform 状态文件转而攻击其他连接的 AWS 帐户，以便在整个组织中横向移动。
这次攻击比大多数攻击来得复杂，原因是它从受攻击的 Kubernetes 容器开始传播到受害者的 AWS 帐户。攻击者还了解 AWS 云机制，比如弹性计算云（EC2）角色、Lambda 无服务器函数和 Terraform。最终结果不是一起典型的加密货币劫持攻击。攻击者还有其他更阴险的动机：盗取专有软件。
在去年，云端网络攻击猛增了 56%。最常见的动机是在云端获得持久性、窃取敏感数据以及创建用于挖掘加密货币的 EC2 实例等新资源。这些资源可能会对组织的云账单产生严重影响。但更多侧重间谍活动的动机也依然存在。实际上，攻击者可以利用云资源从事挖掘加密货币之外的勾当。
我们看到的这起复杂攻击涉及多方面，这表明了保护基于云的基础设施的复杂性。单凭漏洞管理解决不了所有问题。有许多工具可以降低来自高级威胁的风险，包括虚拟机、云安全态势管理（CSPM）、云基础设施授权管理（CIEM）、运行时威胁检测和密文管理。
这张信息图显示了杀伤链的主要步骤。不妨先显示攻击的概貌，然后更详细地介绍每个步骤。
第 1 步：攻击者利用托管在 AWS 云帐户内的自管理 Kubernetes 集群中面向公众的服务获得初始访问权。
第 2 步：一旦攻击者获得了 pod 的访问权，恶意软件就能够在执行过程中执行两个初始操作：
通过实例元数据服务（IMDS）v1 中 worker 的临时凭据获得凭据访问权，使用集群角色权限代表 worker 枚举和收集信息。由于授予的权限过大，攻击者能够：
2）找到其他身份和访问管理（IAM）用户的凭据，它们被设置为 Lambda 环境变量，并以明文形式推送到亚马逊 S3 存储桶中。
第 3 步：攻击者使用前一步中发现的凭据来横向移动。他们直接联系 AWS API，进一步枚举帐户，进而收集信息和泄露数据。他们在这一步中能够：
3）通过发现 S3 存储桶中的 Terrraform 状态文件，找到与不同 AWS 帐户相关的 IAM 用户的凭据。
第 4 步：攻击者使用新的凭据再次横向移动，从他们发现的其他 AWS 帐户重复攻击和杀伤链。幸好他们无法枚举资源，因为他们尝试的所有 AWS API 请求都因缺乏权限而失败。
攻击者发现并利用了一项暴露在互联网面前的服务，它部署在 Kubernetes 集群中。一旦他们访问了容器，开始执行不同的操作以发动攻击。
第一个操作是下载和启动挖币软件，以窃取一些内存周期。这是自动化容器威胁的常见伎俩。攻击者启动了脚本 miner.sh，以便运行一个 XMRig 可执行文件以及挖币软件配置文件 config_background.json。
然而，攻击的目的绝不单单是挖币。挖币是攻击者的最初目标，一旦他们访问了受害者的环境，目标就随之改变，或者挖币被用作逃避数据泄露检测的手段。在安装挖币软件期间，我们观察到容器上同时运行一个 bash 脚本，以枚举和提取环境中的额外信息，比如凭据。
为了找到凭据，攻击者直接访问 IMDS。IMDS v1 是在 AWS 中创建自管理集群或 EC2 实例的旧版本时默认使用的版本，它用于配置和管理机器。
从 IMDS v1 检索绑定到 EC2 实例角色的 AWS 临时安全凭据是一种很常见的做法。攻击者可能发现 IAM 角色绑定到运行以下代码的 worker 实例：
查看对 IMDS v1 的恶意请求，我们还发现了对一个不太为人所知的内部端点（ 仅限内部使用 ）的请求，AWS 文档有解释（）。
下面屏幕截图显示了攻击者如何攻击实例元数据端点以及恶意脚本执行了哪些命令来 grep 和检索 IAM 角色密钥。
一旦收集完毕，就可以在短时间内使用这些凭据，以便代表被冒充的 IAM 角色运行操作，直接调用 AWS API。使用 CloudTrail 日志，你可以看到来自使用集群角色的攻击者的第一个 API 调用：
攻击者运行一些 AWS 操作在 AWS 平台上获得持久性，试图创建新的用户 / 组，并将新的访问密钥绑定到现有 IAM 用户。幸好，由于攻击者使用的帐户缺乏权限，所有这些执行都被拒绝了。
不幸的是，AWS 集群角色错误配置，拥有过大的读取权限。本意是允许读取特定的 S3 存储桶，但权限允许角色读取帐户中的一切，这使攻击者得以进一步了解 AWS 帐户，包括 Lambda。
一旦攻击者获得对云帐户的初始访问权，就开始收集关于部署在 AWS 帐户中的资源的信息。下表中报告的活动只是 AWS 帐户中记录的部分 API 请求。
在这些收集活动期间，攻击者将目光放在最常用的 AWS 服务上：无服务器 Lambda 函数和 S3 存储桶。
Lambda 函数及其他无服务器函数常用于执行自定义代码，无需担心底层基础设施，这给了最终用户很大的灵活性。
受影响的 AWS 帐户中有不同的 Lambda 函数，主要与帐户自动化有关。
攻击者开始使用适当的 API 调用枚举和检索位于 AWS 帐户中特定区域的所有 Lambda 函数。比如说，你可以使用以下的 AWS 命令列出函数。说白了，它就是 REST API 调用，因此有许多方法来完成这个任务。
在获得函数列表后，攻击者试图通过下载 Lambda 代码来深入挖掘。他们调用下面的 AWS API，获得了代码位置，从而可以下载组成 Lambda 的代码。在本例中，Lambda 函数拥有专有软件及执行软件所需的密钥。
使用 curl 或 wget 命令，攻击者成功盗取了 Lambda 代码，并从 Lambda 函数盗取了专有代码和软件。还有证据表明攻击者执行了盗取的软件。
攻击者花时间查看 Lambda 函数的环境变量，使用类似以下的命令，找到了同一帐户中与 IAM 用户相关的其他 AWS 凭据：
正如你在攻击下几步中看到的那样，攻击者使用这里找到的凭据对新用户重试枚举K8官网，希望有新的发现或评估帐户内部可能的特权升级。
攻击者常常攻击存储在 S3 存储桶中的资源和文件，以提取信息和凭据。在过去，许多攻击利用了配置错误的 S3 存储桶或没有密码或安全措施就向公众敞开的 S3 存储桶。在这次攻击中，攻击者能够检索和读取超过 1Tb 的信息，包括客户脚本、故障排除工具和日志文件K8官网。
CloudTrail 并不记录存储在 S3 存储桶中的对象的数据事件，除非明确请求此类功能。在本例中，该功能没有开启，因此无法查看有关访问特定对象的信息。但是我们可以肯定攻击者遍历了存储桶、寻找敏感数据。为了在不消耗可用存储的情况下加快搜索速度，他们可能使用了 TruffleHog 等工具K8官网，立即获得新的 AWS 用户凭据，并继续在集群中横向移动。
1 TB 的数据还包括与 Terraform 相关的日志文件，Terraform 在帐户中用于部署部分基础设施。这些 Terraform 文件将在攻击者试图转移到另一个 AWS 帐户的后续步骤中发挥重要作用。
一旦攻击者访问了云帐户，试图禁用受攻击帐户中的 CloudTrail 日志。从下面截图中可见，由于前几个步骤中其中一个受攻击的用户被分配了额外权限，攻击者成功禁用了帐户中配置的一些日志。
由于该操作，我们无法检索另外的攻击证据K8官网。在审查帐户权限时，将禁用或删除安全日志的功能留给尽可能少的用户至关重要。
Terraform 是一个开源基础设施即代码（IaC）工具，用于在云环境中部署、更改或创建基础设施。
为了让 Terraform 知道哪些资源归它控制、以及何时更新和销毁资源，它默认使用了名为 terraform.tfstate 的状态文件。当 Terraform 在持续集成 / 持续交付（CI/CD）管道中被集成和自动化时，要有适当的权限才能访问状态文件。尤其是，运行管道的服务主体需要能够访问保存状态文件的存储帐户容器。这使得像亚马逊 S3 存储桶这样的共享存储成为保存状态文件的理想选择。
然而，Terraform 状态文件以明本形式保管所有数据，这可能包含密文。将密文存储在安全位置以外的任何地方不是好主意，绝不应该放在源代码控制系统中！
攻击者能够列出可用的存储桶，并检索所有数据。若在事件调查期间使用不同的工具（比如 Pacu 和 TruffleHog）分析数据，可以在 S3 存储桶中的 terraform.tfstate 中同时找到明文 IAM 用户访问密钥和密文密钥。以下是来自 TruffleHog 的截图。
这些 IAM 凭据属于第二个连接的 AWS 帐户，从而使攻击者有机会横向移动，在整个组织中传播攻击。
获得新凭据后，攻击者重新启动枚举和信息收集过程，以确定是否可以从这个额外的受攻击帐户获得额外的资源。此外，CloudTrail 记录了上述的连接 AWS 帐户中的可疑活动。
攻击者试图对连接云帐户中的不同 AWS 资源执行枚举。幸好 IAM 用户被界定了明确范围，所以所有请求因缺乏权限而失败，只留下无害的 GetCallerIdentity API，它默认被允许。
本文阐述的攻击清楚地表明威胁分子如何将试图到达云作为主要目的。这一切始于一项受攻击的服务，不过攻击者一旦获得了有效凭据就试图在云端横向移动，找到专有代码等有价值的信息。他们还试图转向其他云帐户以获得更多的信息。
对你的应用程序和面向公众的容器运用漏洞管理周期，及时打上补丁。你会意识到暴露了什么，可以按轻重缓急处理修补活动。
使用 IMDS v2，而不是 IMDS v1。增强版需要面向会话的请求以增强深度防御，以防范未经授权的元数据访问。此外，为了确保只有授权的 pod 才能在集群中承担特定的 IAM 角色，尽可能采用最小权限原则，并使用服务帐户 IAM 角色（IRSA）。IRSA 限制了对资源的访问，降低了未授权访问的风险。未授权的 pod 将坚持使用 IMDS 设置。
不要低估只读访问的功效。面对特定的 AWS 资源（比如 Lambda 函数），即使只读也意味着数据泄露或凭据收集。仅对所需资源设置只读访问范围是保证帐户安全的基础。
监视云帐户中的过时对象。未使用的权限可能很危险，即使是旧的、从未使用的权限。贵组织一旦受攻击，将蒙受重大损失。留意过时的对象和定期评估云对象应该必不可少。
Terraform 是出色的工具，但需小心使用。采取最佳实践，并将状态文件存储在安全位置。若使用 AWS KMS、GCP KMS 或 Azure Key Vault 等密钥管理服务（KMS），可以确保密文安全，需要时加密或解密密文。
总之，SCARLETEEL 攻击始于利用一个易受攻击的 pod。攻击者使用了与 pod 运行所在的节点关联的 IAM 角色相关的身份，然后利用这个角色在云端进行枚举，搜索敏感信息，并盗取专有软件。一旦他们发现了新的凭据，就利用新凭据获得持久性，并试图获得更多特权。
发现攻击后为保护环境而采取的措施包括：禁用和删除用户的访问密钥和密文访问密钥，在进行一些审计和渗透测试后保护易受攻击的应用程序，通过使用限制性策略限制对敏感 S3 存储桶的访问，以及采用额外的最小特权措施以减小潜在的攻击面，防止云端横向移动活动。
在这起复杂攻击中，我们看到了易受攻击的应用程序在缺乏足够的安全措施的情况下，攻击者如何能够深入云环境的底层。这次事件强调了众所周知的道理：首先，零信任和最小特权原则很重要；如果你实施它们，就会减小受攻击的可能性。其次，强大的检测和警报可以帮助你在攻击者进一步深入之前揪出这些活动。