EleKtra-Leak挖矿攻击：攻击者通过迅速窃取(AWS) IAM密钥来挖矿

相关研究人员最近发现了一个异常活跃的攻击活动，研究人员称之为 EleKtra-Leak，它会自动窃取 GitHub 公共存储库中泄漏的身份和访问管理 ( IAM ) 密钥。因此，与该活动相关的攻击者能够创建多个 AWS 弹性计算 ( EC2 ) 实例，用于广泛和持久的加密劫持。

分析发现，攻击者能够在五分钟内识别并使用 GitHub 上首次泄漏的 IAM 密钥，这一发现证明了攻击者是如何利用云自动化技术来实现扩展加密劫持的目标。攻击者似乎使用自动化工具不断复制公共 GitHub 存储库，并扫描泄漏的亚马逊网络服务 ( AWS ) IAM 密钥。

分析过程

调查过程中，研究发现，攻击者可能会识别频繁出现的 AWS 账户 id，以阻止这些账户 id 免受未来的攻击或自动化脚本的攻击。因此，研究人员设计了一种新颖的调查架构来动态创建和泄漏不可归因的 AWS 密钥。

多年来，攻击者越来越多地使用 GitHub 作为攻击的初始载体。GitHub 的一个强大功能是它能够列出所有公共存储库，这使得开发人员和攻击者能够实时跟踪新的存储库。

考虑到这个功能，研究人员选择 GitHub 作为其窃取 AWS 密钥的实验平台，将明文泄露的密钥写入新创建的 GitHub 存储库中的文件中，该存储库是研究人员随机选择并从公共 GitHub 存储库列表中复制的。研究人员将 AWS 密钥泄露到复制存储库中随机创建的文件中，然后在成功提交后将其删除。

一旦将窃取的密钥提交到存储库，研究人员就会立即删除了它们。最初，IAM 密钥使用 Base64 编码。然而，尽管像 trufflehog 这样的工具可以找到泄漏的 Base64 IAM 密钥，但事实上没有攻击者能找到密钥。

研究人员认为，攻击者目前没有使用能够解码 base64 编码密钥的工具，其中一个原因可能是因为这些工具有时会产生噪音并产生许多误报。

研究人员随后进行了以明文形式泄露 AWS 密钥的实验，攻击者发现这些都是明文写的，隐藏在过去提交的一个随机文件中，并添加到复制的 repo 中。

GitHub 扫描

当研究人员在 GitHub 中泄漏 AWS 密钥时，GitHub 的秘密扫描功能发现了它们，然后 GitHub 以编程方式通知 AWS 泄漏的秘钥。这导致 AWS 自动将隔离策略应用于与密钥关联的用户，称为 AWSCompromisedKeyQuarantine。

最初，研究人员保留了 AWS awspromisedkeyquarantine 策略，在攻击者测试泄漏的密钥时被动地监控研究人员的侦察。研究人员有意将 AWS 隔离策略替换为原始的 IAM 策略，以进一步了解整个活动。

需要注意的是，应用 AWS 隔离策略不是因为攻击者发起了攻击，而是因为 AWS 在 GitHub 中发现了密钥。研究人员认为，攻击者可能能够找到 AWS 未自动检测到的已泄漏的 AWS 密钥，并随后在 AWSCompromisedKeyQuarantine 策略之外控制这些密钥。

在研究人员使用泄露密钥进行的实验中，攻击者在 AWS 应用隔离策略后四分钟内开始。下图显示了这些活动的时间轴。

攻击者的活动时间轴

上图最后一行显示，从 CloudTrail 事件 AttachUserPolicy 开始，AWS 在时间 13：30：22 时应用隔离策略。仅仅四分钟后，在 13：34：15，攻击者开始使用 AWS API descripregions 进行侦察。CloudTrail 是一个审计工具，它记录在配置的云资源中发生的和事件。

攻击结构

下图显示了整个自动化攻击结构。GitHub 公共存储库被实时扫描，一旦找到密钥，攻击者的自动化就会开始。

Operation CloudKeys 架构

下图显示，攻击者首先执行 AWS 帐户侦察。

AWS 帐户侦察

在侦察之后，攻击者创建 AWS 安全组，然后在任何可访问的 AWS 区域上最终启动每个区域的多个 EC2 实例。

修改安全组并启动第一个 EC2 实例

研究人员收集的数据表明，攻击者的自动化是在 VPN 环境中进行的。根据 CloudTrail 的日志记录，研究人员在多个地区重复了相同的操作，总共产生了 400 多个 API 调用，加起来只用了 7 分钟。这表明攻击者成功地隐藏了自己的身份，同时对 AWS 账户环境发起了自动攻击。

启动实例和配置

一旦发现 AWS 密钥，自动化的一部分将包括在不同地区运行实例的攻击者。下图显示了有关实例类型及其跨多个区域分布的统计信息。

攻击者使用大格式云虚拟机执行操作，特别是 c5a.24xlarge AWS 实例。加密挖矿操作通常使用大格式云实例，因为它们将提高处理能力，使加密劫持者能够在更短的时间内挖掘更多加密货币。

跨区域实例化的 AWS EC2 实例类型

CloudTrail 日志中没有记录用户数据。为了捕获数据，研究人员对 EC2 卷执行了取证分析。

如下图所示，挖矿自动化在挖矿软件启动 EC2 配置过程中自动显示用户数据。

挖矿软件的配置脚本

下图显示了存储在 Google Drive 中的有效负载。Google Drive url 在设计上是匿名的，无法将此 URL 映射到谷歌 Cloud 用户帐户。下载的有效负载被加密存储，然后在下载时解密，如第 6 行所示。

有效负载是一个已知的挖掘工具，哈希值可以与之前的研究相关联，研究人员认为相同的攻击者使用公开泄漏的 Docker 服务来执行加密劫持。他们还确定了提交给 VirusTotal 的报告，这些报告具有相同的哈希，并使用相同的持久化命名约定 ( "appworker" ) ，如下图所示。

共享相同元数据的已知加密挖掘二进制文件

攻击者使用的 AMI（Amazon Machine Image 类型也很独特，它是用于创建虚拟服务器 ( 即 AWS 环境中的 EC2 实例 ) 的主映像。被识别的映像是私有的，它们没有在 AWS 市场上列出。下图显示了使用以下 AMI 实例的 id。

私有 AMI 映像 id 列表

其中一些图片是 Ubuntu 18 版本。研究人员认为，所有这些攻击指标 ( ioc ) 都表明，这是一个至少可以追溯到 2020 年的长期挖矿活动。

挖矿活动跟踪

如上所述，EC2 实例通过 EC2 用户数据接收它们的挖掘配置。该配置包含每个挖矿软件用于传播其开采的门罗币的门罗币钱包地址。

根据其架构，研究人员可以推测钱包地址是独立用于 AWS 挖矿的。如果是这种情况，连接到池的每个工件都代表一个单独的 Amazon EC2 实例。

攻击者用于此操作的挖掘池是 SupportXMR 挖掘池。矿池用于加密挖矿，作为多个挖矿软件共同工作的工作空间，以增加成功挖矿的机会。

考虑到 SupportXMR 服务只提供某时间段的统计数据，研究人员对钱包进行了数周的监控并提取了挖掘统计数据。下图显示了独立挖矿软件的数量。

XMR 挖矿软件数量统计

在 2023 年 8 月 30 日至 2023 年 10 月 6 日期间，总共出现了 474 个独立挖矿软件，研究人员可以将其解释为在此期间记录的 474 个独立的 Amazon EC2 实例执行挖矿。由于攻击者挖的是门罗币 ( Monero ) ，这是一种包含隐私控制的加密货币，因此研究人员无法跟踪钱包来获得攻击者获得挖矿货币的确切数字。

研究人员将继续监控这一挖矿活动。这与 Unit 42 观察到的攻击者使用可信业务应用程序逃避检测的发现一致。

架构分析

为了开展研究，Prisma 云安全研究团队创建了一个名为 HoneyCloud 的工具，这是一个完全可攻击和可复制的云环境，包含以下功能：

跟踪恶意操作；

跟踪云攻击者的行动；

发现新的云攻击路径；

构建更好的云防御解决方案。

研究人员使用 IaC 模板为 Terraform 创建了一个半随机的 AWS 基础设施。Terraform 是一个 IaC 配置工具，用于管理和维护云基础设施，这个工具允许研究人员使用定时调度和人工分析来创建和破坏基础设施。

由于研究人员之前的 AWS 账户 ID 被添加到攻击者的黑名单中，他们进行了一个 Terraform 设计。该设计在生成的 AWS 账户中引入了一定数量的随机性，其新创建的基础设施帮助研究人员避免了攻击者匹配或识别以前 IAM 密钥泄漏的操作。

研究人员还设计了 Terraform 自动化，根据攻击者在 AWS 账户中执行的活动，使用不同类型的 IAM 策略，该策略或多或少会限制 IAM 权限。

在本次调查中，研究人员遇到的最大障碍便是 AWS 在应用隔离策略，以防止恶意方面的反应速度速度。AWS 在 GitHub 上泄露 AWS 密钥后两分钟内实施了隔离政策。

AWS 隔离策略本可以成功阻止此攻击。然而，在分析了挖矿活动之后，研究人员发现了更多的挖矿实例，这可能是因为密钥以不同的方式或在不同的平台上被泄漏。

为了方便研究，研究人员被迫重写隔离策略，以确保研究人员能够跟踪攻击者的操作。为了执行此操作，研究人员创建了一个单独的监控工具，以恢复我们计划破坏的原始过度宽松的 AWS 安全策略。

自动生成 AWS 云

下图显示了用于公开 AWS IAM 凭据并随后监控针对它们采取操作的总 IaC 架构。

使用 AWS 复制和监控 GitHub 存储库

所设计架构的 IaC 模板负责随机选择 GitHub 存储库，复制和泄漏 AWS IAM 密钥作为过去提交的随机文件。在 AWS 方面，使用相同的 AWS 管理组织和集中式 CloudTrail 日志存储，为 IaC 模板执行的每次迭代动态创建新的 AWS 帐户。

研究人员还在 AWS 管理帐户中开发并部署了一个额外的 lambda 函数，该函数作为监控器收集基础设施更改并跟踪 IAM 用户策略更改。

IaC 模板的主要目标之一是保持 AWS 基础设施组件尽可能随机，以避免被攻击者发现并阻止。另一个目标是允许定期和精确地摧毁基础设施，以便快速和系统地开始新的环境和变量。通过这种方式，攻击者只能将 AWS IAM 密钥视为全新 AWS 环境的一部分，而不是研究环境的一部分。

总结

分析发现，攻击者扫描了公共 GitHub 存储库中泄漏的 AWS IAM 秘钥。研究人员发现，AWS IAM 密钥在公共 GitHub 存储库中泄漏仅五分钟后便可以检测并启动全面的挖矿。

该活动至少从 2020 年就开始了，尽管 AWS 隔离政策取得了成功，但该活动在受害帐户的数量和频率上仍然持续波动，研究人员认为关注泄漏的 GitHub 秘钥或亚马逊 EC2 实例目标仅仅是攻击目标之一。

为了方便分析，研究人员开发了一个半自动化的 IaC Terraform 架构来跟踪该攻击活动，其中就包括动态创建旨在被破坏和销毁的 AWS 账户。

缓解策略

1. 使用 AWS 隔离策略；

2. 使用 Amazon Lightsail，在泄漏的 IAM 密钥提交到 GitHub 存储库的几分钟内，AWS 启动了此隔离。这一隔离策略必须正确使用，以确保潜在的攻击者不会利用敏感的云数据、服务和资源。

无意中泄漏 AWS IAM 秘钥的组织应立即撤销使用该秘钥建立的任何 API 连接，还应从其 GitHub 存储库中删除 AWS IAM 秘钥，并生成新的 AWS IAM 秘钥以实现所需功能。