导语：无意中泄漏AWS IAM秘钥的组织应立即撤销使用该秘钥建立的任何API连接，还应从其GitHub存储库中删除AWS IAM秘钥，并生成新的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秘钥以实现所需功能。
文章翻译自：https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking/如若转载，请注明原文地址
