相關研究人員最近發現了一個異常活躍的攻擊活動，研究人員稱之爲 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 秘鑰以實現所需功能。
