APT & 針對式目標攻擊
TeamTNT 持續攻擊雲端，瞄準 AWS 執行個體
TeamTNT 駭客集團經常竊取 Amazon Web Services (AWS)、Docker 與 Linux Secure Shell (SSH) 的登入憑證，此外也從事其它惡意活動，包括在 Linux 裝置上挖礦或植入後門程式 (如 IRC 殭屍程式與遠端指令列腳本)。不過，該集團的攻擊範圍當時仍是個謎。趨勢科技在分析該集團的活動時發現了一個二進位檔案內含一段寫死的指令列腳本 (shell script) 專門用來竊取 AWS 登入憑證，進而掌握了該集團的攻擊範圍。
趨勢科技首先分析了一個新的 AWS 登入憑證竊取程式所植入的腳本。此攻擊與其它 TeamTNT 的攻擊行動類似，都是利用組態設定錯誤 (例如：對外開放的 Redis 執行個體，以及外洩的安全指令列登入憑證) 或經由漏洞來取得系統的遠端存取權限，然後部署下一階段的惡意程式，例如安裝挖礦(coinmining)程式。接下來，駭客就能將該腳本植入目標環境。
如圖 2 所示，該腳本會利用 AWS 的 metadata 服務來搜尋登入憑證。不論搜尋是否成功，該腳本都會建立一個檔案並將該檔上傳到遠端一台專門接收竊取資料的網站伺服器。
儘管這個腳本的設計是要在 AWS 執行個體中執行，但根據我們分析，它在任何 Linux 電腦、容器或雲端執行個體上都能運作。只不過它大部分時間都無法取得有用的資料。
前述網站伺服器上的目錄被設定開放 (也許是設定錯誤)，所有上傳的檔案都能被存取，包括後續攻擊目標的資料、竊取的檔案，以及持續中攻擊的統計數據。
該伺服器除了保存竊取的資料之外，也儲存了一些 Linux 虛擬加密貨幣挖礦工具，這些是駭客用來植入受害系統的檔案，同時也是他們的目標之一。
當駭客在某個 AWS 執行個體中成功執行惡意腳本時，AWS 客戶的安全資訊就會因而外洩並遭歹徒用於其他惡意用途。
結論與影響
我們在研究期間發現了超過 4,000 個感染案例。雖然這些案例並不一定都是 AWS 執行個體，但駭客所使用的惡意程式卻是專門針對 AWS 使用者所設計 (因為該腳本會搜尋 AWS 服務的 metadata，而這些資料唯有 AWS 服務才有)。在所有感染案例中，約有 5% (也就是大約 200 個) 含有 AWS 客戶的機敏資訊。
就地區而言，受害最深的 AWS 地區是美國 (us-east-1a)，約占所有感染案例的 28%。其次是中國 (cn-northwest-1c)，占 9%。非重複的 ID 共有 31 個，前三名加起來就占了所有 198 個失竊金鑰中的 67 個。根據檔案的日期和時間，可推測該集團的攻擊大概從 2021 年 2 月 10 日開始。除此之外，趨勢科技也推測這些檔案的數量就代表了受感染的電腦數量。在觀察 TeamTNT 一陣子之後，現在我們可以推斷它們應該是隨著 IT 產業的潮流發展而開始移轉到雲端。
建議與解決方案
有鑑於犯罪集團越來越重視雲端，企業機構應該採取一些必要的措施，盡可能確保雲端基礎架構的安全。絕大部分的雲端服務供應商 (包括 AWS 在內) 都採用共同分擔責任的雲端安全架構。在這樣的架構下，雲端廠商須負責雲端基礎架構的安全，包括用來執行雲端服務的硬體、軟體、網路及廠房設備。至於客戶，則必須保護自己放到雲端服務上的一切。儘管確切的內容需視客戶所採用的雲端服務類型而定，但一般來說客戶需要負責保護的部分是自己的資料、平台、應用程式、作業系統、網路組態設定等等。
我們建議企業應考慮採取以下資安措施：
- 優先導入裝置的持續監控與稽核，尤其是用來存取企業網路的裝置。
- 採取最低授權原則，不需開放的權限就不要開放，如此可縮小受攻擊面並削減攻擊的破壞力。舉 TeamTNT 攻擊為例，如果只讓必要的使用者存取安全資訊，就能有助於防止歹徒洩漏這些資訊。
- 定期修補及更新系統以降低遭到漏洞攻擊的風險。
- 使用高強度密碼並啟用多重認證。
此外，Amazon 也提供了一些額外的建議來教您如何保護 AWS 資源，包括建立一組高強度密碼、採用AWS帳號的群組郵件、開啟多重要素驗證、設定AWS IAM使用者/群組/角色、刪除帳號存取金鑰、在所有的AWS地區開啟CloudTrail；同時Amazon也提供了 Amazon GuardDuty、Amazon Macie 及 AWS Security Hub 這類服務來提升雲端實作的安全。
趨勢科技建議，企業應該尋找一套能夠符合不論是雲端移轉或是DevOps過程都能支援的資安解決方案，例如Trend Micro Cloud One™不僅能為雲端原生系統從多個層次提供防護，也可以保護持續整合/持續交付 (CI/CD) 流程與應用程式。
原文出處：TeamTNT Continues Attack on the Cloud, Focuses on AWS Instances