写在前面的话

近期，研究人员对一个名为Elektra-Leak的恶意活动进行了持续跟踪和深入分析，并发现相关的威胁行为者在Elektra-Leak恶意活动中能够实现在公共GitHub代码库内自动获取IAM（身份和访问管理）凭证信息。因此，相关威胁行为者将能更够使用暴露的凭证信息创建多个AWS弹性计算（EC2）实例，并将其用于广泛而持久的密码劫持活动。

事件背景

从安全研究的角度来看，AWS密钥泄漏的严重性在于一旦威胁行为者识别出了这些密钥，就可以轻易将其应用到目标AWS账号上。这些年来，攻击者增加了针对GitHub的使用频率，这也使得他们能够实时跟踪新的存储库。

鉴于这种能力，我们选择GitHub作为我们泄露AWS密钥实验的平台。我们会将泄露的明文密钥写入新创建GitHub存储库中的一个文件内，而该存储库则是我们从公共GitHub库列表中随机选择并克隆的。我们计划将AWS密钥泄露到克隆存储库中随机创建的文件中，然后在成功提交后将其删除。一旦泄露的密钥被提交到存储库，我们会立即删除它们，以此来增加实验环境的真实性，从而吸引更多的威胁参与者进入我们的实验环境。

GitHub扫描操作

当我们将AWS密钥暴露在GitHub上时，GitHub的敏感信息扫描功能会立刻识别到泄漏的密钥，然后GitHub会以编程方式通知AWS暴露的凭据。这导致AWS自动将隔离策略应用于与密钥关联的用户，即AWSCompromisedKeyQuarantine。此策略可以有效防止威胁行为者执行某些操作，因为AWS会自动取消成功利用AWS IAM和EC2以及与暴露的IAM凭证相关的其他API服务操作能力。

最初，我们保留了AWS AWSCompromisedKeyQuarantine策略，并在威胁行为者测试暴露密钥时被动监控其侦察操作。需要注意的是，应用AWS隔离策略并不是因为威胁行为者发起了攻击，而是因为AWS在GitHub中扫描到了暴露的密钥。我们相信，威胁参与者可以找到未被AWS自动检测到的暴露的AWS密钥，并随后在AWSCompromisedKeyQuarantine策略之外控制这些密钥。事实证明，也确实是如此，在这种情况下，威胁行为者可以在没有政策干预的情况下，从目标那里窃取资源并继续进行攻击。

但是在某些情况下，即便是AWS密钥发生泄漏，GitHub和AWS所实现的保护级别也无法覆盖所有场景。

在我们的密钥泄漏实验中，威胁参与者会在AWS应用隔离政策后的四分钟内开始了他们的操作，活动时间如下图所示：

如上图所示，从CloudTrail的AttachUserPolicy事件开始，AWS在时间戳13:30:22应用隔离策略。仅仅四分钟后，也就是13:34:15，威胁行为者就开始使用AWS API DescribeRegions来执行网络侦查活动了。其中的CloudTrail是一个安全审计工具，可以用于记录配置的云资源中发生的操作和事件。

威胁行为者操作流程

下图显示的是威胁行为者的自动化操作流程架构，他们可以实时扫描GitHub公开代码库，一旦检测到了泄漏的密钥，他们就会开始执行自动化任务：

下图显示的是威胁行为者针对某个AWS账号执行的网络侦查活动：

侦查活动结束后，威胁行为者在启动多个EC2实例（跨AWS区域）将创建AWS安全组：

我们收集的数据表明，攻击者所有的自动化操作都是通过虚拟专用网络V*P*N进行的。根据CloudTrail日志记录，他们在多个地区重复了相同的操作，总共生成了400多个API调用，用时仅7分钟。这表明，攻击者能够成功隐藏他们的真实身份，并同时对多个AWS账号环境发起自动化攻击。

启动实例和配置

找到泄漏的 AWS密钥之后，攻击者会尝试以自动化的形式在不同区域运行实例：

接下来，攻击者将使用RunInstance API实例化Amazon EC2实例，该API有一个用于接受AWS Cloud-Init脚本的参数，而Cloud-Init则会在实例启动过程中执行，攻击者可以使用该机制来自动化EC2实例配置并执行所需的操作。

由于CloudTrail日志中未记录用户数据，为了获取数据，我们对EC2卷进行了取证分析。具体如下图所示，攻击者部署了自动挖矿程序，并且会在启动EC2挖矿实例时自动显示用户数据：

根据下图中的数据，攻击者的Payload存储在Google Drive中，但Google Drive URL是匿名的，因此无法将此URL映射到Google Cloud用户帐户。下载的Payload经过了加密处理，并会在下载时进行解密。通过哈希对比之后，我们发现这个Payload是一种挖矿工具：

攻击者所使用的AMI类型也非常独特，我们已识别的镜像是私有镜像，，它们没有在AWS Marketplace中列出：

其中有一些镜像为Ubuntu v18版本，而所有的IoC都表明，这一恶意挖矿活动至少可以追溯到2020年。

恶意挖矿活动跟踪

如上所述，EC2实例通过EC2用户数据接收其挖掘配置。配置包含每个矿工程序用于交付其开采的门罗币的钱包地址。

鉴于威胁行为者的操作架构，我们可以推测这个钱包地址是专门用于AWS挖掘操作的，在这种情况下，每个连接到矿池的工作线程都代表一个单独的AmazonEC2实例。攻击者使用的是SupportXMR矿池，它同时也是多个矿工程序进行挖矿工作的工作区，奖励发放后，收益将平均分配给为该矿池中的矿工程序：

2023年8月30日至2023年10月6日期间，共有474个不同的矿工程序出现。我们可以将其理解为474个单独的AmazonEC2实例，这些实例在此期间将负责执行挖掘操作。

考虑到威胁行为者正在使用虚拟专用网络V*P*N和Google Drive来交付Payload，因此我们很难对其进行地理位置分析。

AWS Cloud自动生成

下图显示的是威胁行为者获取到泄漏的AWS IAM凭证之后，会采取操作的整体架构流程图：

威胁行为者首先会随机选择GitHub代码库，然后克隆并检索其中暴露的AWS IAM密钥，并在随机文件中提交。针对AWS，他们使用了相同的AWS管理组织和中心化CloudTrail日志存储。我们还在AWS管理帐户中开发和部署了一个额外的lambda函数，该函数充当监控器，以收集基础架构更改并跟踪IAM用户策略更改。

入侵威胁指标

加密文档

Backup.tib：

SHA256: 87366652c83c366b70c4485e60594e7f40fd26bcc221a2db7a06debbebd25845

矿工哈希

Appworker：

SHA256: 240fe01d9fcce5aae311e906b8311a1975f8c1431b83618f3d11aeaff10aede3

脚本哈希

EC2用户数据：

SHA256: 2f0bd048bb1f4e83b3b214b24cc2b5f2fd04ae51a15aa3e301c8b9e5e187f2bb

域名

XMR矿池地址：pool[.]supportxmr[.]com:443

门罗币钱包地址

82sdgJwuAMTF6w76Q7KrN4jJL72v23gvf9K2favHYHKxCNP4UabmBsJMwAVGWDLYagW5UmykC2D1zaMoQegZLy2bF9ynM1E

参考链接

https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking/