By HireHackking in HACKER
· 2 views
相關研究人員最近發現了一個異常活躍的攻擊活動，研究人員稱之為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 Driveurl在設計上是匿名的，無法將此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秘鑰以實現所需功能。
Recommended Comments