SCARLETEEL：利用Terraform、Kubernetes和AWS竊取數據的黑客活動

Sysdig威脅研究團隊最近在客戶環境中發現了一起導致專有數據被盜的復雜云活動：SCARLETEEL。攻擊者利用容器化的工作負載將特權升級到AWS帳戶，以便盜取專有軟件和憑據。他們還企圖使用Terraform狀態文件轉而攻擊其他連接的AWS帳戶，以便在整個組織中橫向移動。

這次攻擊比大多數攻擊來得復雜，原因是它從受攻擊的Kubernetes容器開始傳播到受害者的AWS帳戶。攻擊者還了解AWS云機制，比如彈性計算云（EC2）角色、Lambda無服務器函數和Terraform。最終結果不是一起典型的加密貨幣劫持攻擊。攻擊者還有其他更陰險的動機：盜取專有軟件。

在去年，云端網絡攻擊猛增了56%。最常見的動機是在云端獲得持久性、竊取敏感數據以及創建用于挖掘加密貨幣的EC2實例等新資源。這些資源可能會對組織的云賬單產生嚴重影響。但更多側重間諜活動的動機也依然存在。實際上，攻擊者可以利用云資源從事挖掘加密貨幣之外的勾當。

我們看到的這起復雜攻擊涉及多方面，這表明了保護基于云的基礎設施的復雜性。單憑漏洞管理解決不了所有問題。有許多工具可以降低來自高級威脅的風險，包括虛擬機、云安全態勢管理（CSPM）、云基礎設施授權管理（CIEM）、運行時威脅檢測和密文管理。

概述

這張信息圖顯示了殺傷鏈的主要步驟。不妨先顯示攻擊的概貌，然后更詳細地介紹每個步驟。

圖1

第1步：攻擊者利用托管在AWS云帳戶內的自管理Kubernetes集群中面向公眾的服務獲得初始訪問權。

第2步：一旦攻擊者獲得了pod的訪問權，惡意軟件就能夠在執行過程中執行兩個初始操作：

啟動加密貨幣挖掘軟件，以便牟利或分散注意力。

通過實例元數據服務（IMDS）v1中worker的臨時憑據獲得憑據訪問權，使用集群角色權限代表worker枚舉和收集信息。由于授予的權限過大，攻擊者能夠：

1）枚舉AWS資源。

2）找到其他身份和訪問管理（IAM）用戶的憑據，它們被設置為Lambda環境變量，并以明文形式推送到亞馬遜S3存儲桶中。

第3步：攻擊者使用前一步中發現的憑據來橫向移動。他們直接聯系AWS API，進一步枚舉帳戶，進而收集信息和泄露數據。他們在這一步中能夠：

1）禁用CloudTrail日志以逃避檢測。

2）盜取專有軟件。

3）通過發現S3存儲桶中的Terrraform狀態文件，找到與不同AWS帳戶相關的IAM用戶的憑據。

第4步：攻擊者使用新的憑據再次橫向移動，從他們發現的其他AWS帳戶重復攻擊和殺傷鏈。幸好他們無法枚舉資源，因為他們嘗試的所有AWS API請求都因缺乏權限而失敗。

技術分析

初始訪問——容器受攻擊

攻擊者發現并利用了一項暴露在互聯網面前的服務，它部署在Kubernetes集群中。一旦他們訪問了容器，開始執行不同的操作以發動攻擊。

第一個操作是下載和啟動挖幣軟件，以竊取一些內存周期。這是自動化容器威脅的常見伎倆。攻擊者啟動了腳本miner.sh，以便運行一個XMRig可執行文件以及挖幣軟件配置文件config_background.json。

圖2

圖3

圖4

然而，攻擊的目的絕不單單是挖幣。挖幣是攻擊者的最初目標，一旦他們訪問了受害者的環境，目標就隨之改變，或者挖幣被用作逃避數據泄露檢測的手段。在安裝挖幣軟件期間，我們觀察到容器上同時運行一個bash腳本，以枚舉和提取環境中的額外信息，比如憑據。

為了找到憑據，攻擊者直接訪問IMDS。IMDS v1是在AWS中創建自管理集群或EC2實例的舊版本時默認使用的版本，它用于配置和管理機器。

從IMDS v1檢索綁定到EC2實例角色的AWS臨時安全憑據是一種很常見的做法。攻擊者可能發現IAM角色綁定到運行以下代碼的worker實例：

role_name=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)

然后獲取AccessKeyId、SecretAccessKey和臨時令牌：

metadata_content=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$role_name)

查看對IMDS v1的惡意請求，我們還發現了對一個不太為人所知的內部端點（“僅限內部使用”）的請求，AWS文檔有解釋（https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instancedata-data-categories.html）。

metadata_content=$(curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)

下面屏幕截圖顯示了攻擊者如何攻擊實例元數據端點以及惡意腳本執行了哪些命令來grep和檢索IAM角色密鑰。

圖5

一旦收集完畢，就可以在短時間內使用這些憑據，以便代表被冒充的IAM角色運行操作，直接調用AWS API。使用CloudTrail日志，你可以看到來自使用集群角色的攻擊者的第一個API調用：

圖6

攻擊者運行一些AWS操作在AWS平臺上獲得持久性，試圖創建新的用戶/組，并將新的訪問密鑰綁定到現有IAM用戶。幸好，由于攻擊者使用的帳戶缺乏權限，所有這些執行都被拒絕了。

不幸的是，AWS集群角色錯誤配置，擁有過大的讀取權限。本意是允許讀取特定的S3存儲桶，但權限允許角色讀取帳戶中的一切，這使攻擊者得以進一步了解AWS帳戶，包括Lambda。

發現——AWS云

一旦攻擊者獲得對云帳戶的初始訪問權，就開始收集關于部署在AWS帳戶中的資源的信息。下表中報告的活動只是AWS帳戶中記錄的部分API請求。

圖7

在這些收集活動期間，攻擊者將目光放在最常用的AWS服務上：無服務器Lambda函數和S3存儲桶。

Lambda函數枚舉——盜取專有代碼和軟件

Lambda函數及其他無服務器函數常用于執行自定義代碼，無需擔心底層基礎設施，這給了最終用戶很大的靈活性。

受影響的AWS帳戶中有不同的Lambda函數，主要與帳戶自動化有關。

攻擊者開始使用適當的API調用枚舉和檢索位于AWS帳戶中特定區域的所有Lambda函數。比如說，你可以使用以下的AWS命令列出函數。說白了，它就是REST API調用，因此有許多方法來完成這個任務。

aws lambda list-functions

在獲得函數列表后，攻擊者試圖通過下載Lambda代碼來深入挖掘。他們調用下面的AWS API，獲得了代碼位置，從而可以下載組成Lambda的代碼。在本例中，Lambda函數擁有專有軟件及執行軟件所需的密鑰。

aws lambda get-function --function-name $function_name --query 'Code.Location'

使用curl或wget命令，攻擊者成功盜取了Lambda代碼，并從Lambda函數盜取了專有代碼和軟件。還有證據表明攻擊者執行了盜取的軟件。

攻擊者花時間查看Lambda函數的環境變量，使用類似以下的命令，找到了同一帳戶中與IAM用戶相關的其他AWS憑據：

aws lambda list-versions-by-function --function-name $function_name

正如你在攻擊下幾步中看到的那樣，攻擊者使用這里找到的憑據對新用戶重試枚舉，希望有新的發現或評估帳戶內部可能的特權升級。

S3存儲桶枚舉

亞馬遜S3是一種非常流行的存儲服務，允許用戶存儲和檢索數據。

攻擊者常常攻擊存儲在S3存儲桶中的資源和文件，以提取信息和憑據。在過去，許多攻擊利用了配置錯誤的S3存儲桶或沒有密碼或安全措施就向公眾敞開的S3存儲桶。在這次攻擊中，攻擊者能夠檢索和讀取超過1Tb的信息，包括客戶腳本、故障排除工具和日志文件。

圖8

CloudTrail并不記錄存儲在S3存儲桶中的對象的數據事件，除非明確請求此類功能。在本例中，該功能沒有開啟，因此無法查看有關訪問特定對象的信息。但是我們可以肯定攻擊者遍歷了存儲桶、尋找敏感數據。為了在不消耗可用存儲的情況下加快搜索速度，他們可能使用了TruffleHog等工具，立即獲得新的AWS用戶憑據，并繼續在集群中橫向移動。

1 TB的數據還包括與Terraform相關的日志文件，Terraform在帳戶中用于部署部分基礎設施。這些Terraform文件將在攻擊者試圖轉移到另一個AWS帳戶的后續步驟中發揮重要作用。

防御逃避——禁用CloudTrail日志

一旦攻擊者訪問了云帳戶，試圖禁用受攻擊帳戶中的CloudTrail日志。從下面截圖中可見，由于前幾個步驟中其中一個受攻擊的用戶被分配了額外權限，攻擊者成功禁用了帳戶中配置的一些日志。

圖9

由于該操作，我們無法檢索另外的攻擊證據。在審查帳戶權限時，將禁用或刪除安全日志的功能留給盡可能少的用戶至關重要。

憑據訪問——Terrraform狀態文件

Terraform是一個開源基礎設施即代碼（IaC）工具，用于在云環境中部署、更改或創建基礎設施。

為了讓Terraform知道哪些資源歸它控制、以及何時更新和銷毀資源，它默認使用了名為terraform.tfstate的狀態文件。當Terraform在持續集成/持續交付（CI/CD）管道中被集成和自動化時，要有適當的權限才能訪問狀態文件。尤其是，運行管道的服務主體需要能夠訪問保存狀態文件的存儲帳戶容器。這使得像亞馬遜S3存儲桶這樣的共享存儲成為保存狀態文件的理想選擇。

然而，Terraform狀態文件以明本形式保管所有數據，這可能包含密文。將密文存儲在安全位置以外的任何地方不是好主意，絕不應該放在源代碼控制系統中！

攻擊者能夠列出可用的存儲桶，并檢索所有數據。若在事件調查期間使用不同的工具（比如Pacu和TruffleHog）分析數據，可以在S3存儲桶中的terraform.tfstate中同時找到明文IAM用戶訪問密鑰和密文密鑰。以下是來自TruffleHog的截圖。

圖10

這些IAM憑據屬于第二個連接的AWS帳戶，從而使攻擊者有機會橫向移動，在整個組織中傳播攻擊。

橫向移動——AWS帳戶

獲得新憑據后，攻擊者重新啟動枚舉和信息收集過程，以確定是否可以從這個額外的受攻擊帳戶獲得額外的資源。此外，CloudTrail記錄了上述的連接AWS帳戶中的可疑活動。

攻擊者試圖對連接云帳戶中的不同AWS資源執行枚舉。幸好IAM用戶被界定了明確范圍，所以所有請求因缺乏權限而失敗，只留下無害的GetCallerIdentity API，它默認被允許。

圖11

建議

本文闡述的攻擊清楚地表明威脅分子如何將試圖到達云作為主要目的。這一切始于一項受攻擊的服務，不過攻擊者一旦獲得了有效憑據就試圖在云端橫向移動，找到專有代碼等有價值的信息。他們還試圖轉向其他云帳戶以獲得更多的信息。

以下是可以幫助你更謹小慎微的幾個建議：

對你的應用程序和面向公眾的容器運用漏洞管理周期，及時打上補丁。你會意識到暴露了什么，可以按輕重緩急處理修補活動。

使用IMDS v2，而不是IMDS v1。增強版需要面向會話的請求以增強深度防御，以防范未經授權的元數據訪問。此外，為了確保只有授權的pod才能在集群中承擔特定的IAM角色，盡可能采用最小權限原則，并使用服務帳戶IAM角色（IRSA）。IRSA限制了對資源的訪問，降低了未授權訪問的風險。未授權的pod將堅持使用IMDS設置。

不要低估只讀訪問的功效。面對特定的AWS資源（比如Lambda函數），即使只讀也意味著數據泄露或憑據收集。僅對所需資源設置只讀訪問范圍是保證帳戶安全的基礎。

監視云帳戶中的過時對象。未使用的權限可能很危險，即使是舊的、從未使用的權限。貴組織一旦受攻擊，將蒙受重大損失。留意過時的對象和定期評估云對象應該必不可少。

Terraform是出色的工具，但需小心使用。采取最佳實踐，并將狀態文件存儲在安全位置。若使用AWS KMS、GCP KMS或Azure Key Vault等密鑰管理服務（KMS），可以確保密文安全，需要時加密或解密密文。

攻擊總結和結論

總之，SCARLETEEL攻擊始于利用一個易受攻擊的pod。攻擊者使用了與pod運行所在的節點關聯的IAM角色相關的身份，然后利用這個角色在云端進行枚舉，搜索敏感信息，并盜取專有軟件。一旦他們發現了新的憑據，就利用新憑據獲得持久性，并試圖獲得更多特權。

發現攻擊后為保護環境而采取的措施包括：禁用和刪除用戶的訪問密鑰和密文訪問密鑰，在進行一些審計和滲透測試后保護易受攻擊的應用程序，通過使用限制性策略限制對敏感S3存儲桶的訪問，以及采用額外的最小特權措施以減小潛在的攻擊面，防止云端橫向移動活動。

在這起復雜攻擊中，我們看到了易受攻擊的應用程序在缺乏足夠的安全措施的情況下，攻擊者如何能夠深入云環境的底層。這次事件強調了眾所周知的道理：首先，零信任和最小特權原則很重要；如果你實施它們，就會減小受攻擊的可能性。其次，強大的檢測和警報可以幫助你在攻擊者進一步深入之前揪出這些活動。

攻陷指標（IOC）

IP地址：80[.]239[.]140[.]66, 45[.]9[.]148[.]221, 45[.]9[.]148[.]121, 45[.]9[.]249[.]58