AWS密鑰泄漏嚴重性在于一旦威脅行為者識別出了這些密鑰

寫在前面的話

近期，研究人員對一個名為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/?