勒索病毒
LockBit 是假的、損害是真的：勒索病毒利用 AWS S3 竊取資料
本文揭露了一個利用 AWS S3 來竊取資料的 Golang 勒索病毒，此勒索病毒會假扮成 LockBit 來讓受害者備感壓力。由於此勒索病毒樣本當中還發現了一些寫死的 AWS 登入憑證，因此也導致對應的 AWS 帳號遭到停用。
重點摘要
- 我們發現了一個使用 Golang 撰寫的勒索病毒會利用 Amazon S3 (Simple Storage Service) Transfer Acceleration 傳輸加速功能來將受害者的檔案上傳到駭客掌控的 S3 儲存貯體。
- 勒索病毒樣本內含一些寫死的 Amazon Web Services (AWS) 登入憑證，不僅可用來追蹤涉入惡意活動的 AWS 帳號 ID，還可當成重要的入侵指標 (IoC)。
- 此 Golang 勒索病毒會冒充惡名昭彰的 LockBit 勒索病毒，此舉應該是為了利用 LockBit 勒索病毒家族的惡名來讓受害者備感壓力。
- 我們已經將研究發現通報給 AWS Security 團隊，很重要一點要說明的是，我們的通報內容並非關於 AWS 服務的任何漏洞，我們只是向 AWS 確認了我們發現的駭客行為，並發現該行為已違反 AWS 的使用政策 (https://aws.amazon.com/aup/)。此外，我們通報的 AWS 存取金鑰和帳號目前也已經都被停用。
簡介
從資訊竊取程式研發到資料外傳，雲端服務供應商越來越常被駭客濫用，用以從事惡意活動。儘管我們檢視的勒索病毒樣本當中含有寫死的 AWS 登入憑證，但這只是單一駭客的作法，一般來說，勒索病毒開發者會利用其他線上服務來配合他們的攻擊手法。針對這點，我們檢視了使用 Go 語言 (亦稱 Golang) 開發的 Windows 和 MacOS 環境勒索病毒樣本。這些樣本絕大多數都含有寫死的 AWS 登入憑證，而竊取的資料也會被上傳到駭客掌控的 Amazon S3 儲存貯體。
在攻擊的最後，裝置的桌布會變成一張含有 LockBit 字樣的圖片。這可能會讓使用者以為這是一起 LockBit 感染事件，尤其 LockBit 勒索病毒家族近年來一直相當活躍，甚至在今年上半年擁有最高的檔案偵測數量。但實際並非如此，駭客似乎只是利用 LockBit 的惡名來加深受害者的恐懼。
我們懷疑勒索病毒作者使用的是自己的 AWS 帳號，或是已遭入侵的 AWS 帳號。我們發現了 30 多個勒索病毒樣本，這些樣本很可能都來自同一作者，這表示駭客在 AWS 停用其存取金鑰和 AWS 帳號之前，一直在積極開發和測試這款勒索病毒。此外，透過寫死的登入憑證 (AWS 存取金鑰 ID)，就能找到對應的 AWS 帳號 ID。這項發現提供了另一個思考方向，那就是：可以將惡意或已遭入侵的 AWS 帳號 ID 當成跨帳號活動的一項入侵指標。
本文探討這些樣本、它們的功能，以及它們如何將 Amazon S3 功能應用於攻擊當中。
技術面分析
Golang 讓開發人員只需撰寫一套核心原始程式碼，就能搭配不同平台的相依元件來進行組譯，進而產生對應該平台的執行檔，這讓開發專案能跨平台移植而不會被綁死。駭客正是看上了這些優點，所以使用 Golang 來製作各種惡意檔案，例如 Agenda 勒索病毒，以及最新發現且 Earth Lusca 正在使用的 KTLVdoor 後門程式。
在我們分析到的勒索病毒樣本當中，絕大多數都含有寫死的 AWS 存取金鑰 ID (Access Key ID) 和存取密鑰 (Secret Access Key)。當我們在研究樣本的內部運作時，我們發現它使用了一個名叫「S3 Transfer Acceleration」(S3TA) 的 AWS S3 功能。
我們的分析主要根據以下樣本：
- 14fe0071e76b23673569115042a961136ef057848ad44cf35d9f2ca86bd90d31
- 0c54e79e8317e73714f6e88df01bda2c569ec84893a7a33bb6e8e4cf96980430
當勒索病毒在受感染的電腦上執行時，首先會執行以下步驟來初始化：
- 取得主機的通用唯一識別碼 (UUID)。
- 匯入寫死的公開金鑰。
此公開金鑰使用隱私增強郵件 (Privacy Enhanced Mail，簡稱 PEM) 格式來加以編碼。
公開金鑰的數值解碼後顯示它使用了 RSA 加密與 2048 位元的模數 (modulus)。
- 隨機產生的「主金鑰」是使用先前匯入的 RSA 公開金鑰來產生與加密。(這表示只有擁有私密金鑰的駭客才能用它來解開主金鑰。)
- 將加密後的主金鑰寫入讀我檔案 (README.txt)。
- 使用 AWS SDK for Go v2 函式庫的 StaticCredentialsProvider 來載入靜態登入憑證。靜態登入憑證包括寫死的 AccessKeyID、SecretAccessKey 以及 AWS_REGION。
在初始化之後，勒索病毒會呼叫 filepath.Walk 函式來列出「/」目錄 (macOS 變種的根目錄) 當中的所有檔案。每個列舉出來的檔案都會進一步核對它是否位於要排除的資料夾內。如果是，該檔案就不會加密。
勒索病毒含有一份要被加密的副檔名清單 (通常是文件、照片和資料檔案)。
README.txt 檔案不會被加密。
資料外傳
勒索病毒樣本會根據所取得的主機 UUID，使用一組寫死的登入憑證在駭客掌控的 AWS 帳號上建立一個 Amazon S3 儲存貯體。
建立儲存貯體之後，就會修改組態設定來啟用 S3TA 功能。
最後一步是將檔案從頭到尾加密。加密演算法是 AES-CTR，密碼是「檔案名稱」與「主金鑰」拼湊在一起之後計算出來的 MD5 雜湊碼。
例如，勒索病毒會隨機產生 16 位元組的主金鑰「20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12」。要被加密的檔案名稱是「text.txt」。
所以拼湊後的位元組順序是「74 65 78 74 2E 74 78 74 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12」，計算出來的 MD5 雜湊碼則是「23 a3 ec c5 58 2d 97 41 07 3c 3b dc 31 7d 49 30」。
接著，檔案會從受害者的電腦上傳到駭客掌控的 AWS 帳號。
S3TA 能讓使用者更快地從遠距離傳輸資料。它利用了 Amazon CloudFront 遍布全球的邊緣據點。要使用此功能，必須在儲存貯體上啟用此功能。儲存貯體名稱應符合網域名稱系統 (DNS) 規範，且不得有英文句點。視 AWS 環境的類型而定，已啟用 S3TA 的 S3 儲存貯體可以被下列端點存取：
- bucketname[.]s3-accelerate.amazonaws.com
- bucketname[.]s3-accelerate.dualstack.amazonaws.com
每個通過先前的副檔名檢查且大小低於 100 Mebibyte (MiB) 的檔案都會呼叫 Uploader.Upload 函式來上傳到 AWS。這是因為要節省 AWS 的空間和費用，因為上傳大檔案會讓駭客花更多錢。
最後一步是將檔案從頭到尾加密。加密演算法是 AES-CTR，密碼是「檔案名稱」與「主金鑰」拼湊在一起之後計算出來的 MD5 雜湊碼。
勒索病毒會隨機產生一個 16 位元組的主金鑰 (例如「63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12」)。要被加密的檔案名稱是「text.txt」。
所以，拼湊後的位元組序列是「74 65 78 74 2E 74 78 74 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12」，計算出來的 MD5 雜湊值則是「23 a3 ec c5 58 2d 97 41 07 3c 3b dc 31 7d 49 30」，如下圖所示 (經由 CyberChef 產生，在此僅供視覺化用途)。
產生出來的雜湊碼會當成 crypto.AES.NewCipher 函式的 AES 金鑰參數。初始化向量是隨機產生的 16 位元組，會傳入 crypto.cipher.NewCTR 函式。
被加密之後的檔案會依照以下格式重新命名：「<original file name>.<initialization vector>.abcd」。例如，「text.txt」檔案將重新命名為「text.txt.e5c331611dd7462f42a5e9776d2281d3.abcd」。
我們在除錯器當中執行了勒索病毒樣本並擷取出主金鑰。接著，我們確認我們可以正確解開先前加密的檔案，只要選擇適當的密碼並傳入正確的參數即可，如下圖所示 (經由 CyberChef 產生，在此僅供視覺化用途)。
README.txt 檔案內含 base64 編碼內容。解碼之後就會顯示一個由 crypto.rsa.EncryptPKCS1v15 加密的主金鑰 (加密時是以一個寫死的公開金鑰作為參數，接著再以 base64 編碼)。此 base64 編碼的二進位大型物件 (Blob) 後面接著是主機名稱、作業系統版本以及被感染的電腦識別碼。要解開主金鑰，我們需要勒索病毒開發人員的私密金鑰，但我們並沒有。
當所有檔案都處理完畢之後，勒索病毒就會變更裝置的桌布。我們發現它使用了兩個不同的桌布，兩者都是從 LockBit 攻擊或某篇提到該勒索病毒家族的資安部落格竊取或複製而來。但值得注意的是，最新的 LockBit 版本並非 2.0 版。此外，勒索病毒集團背後的重要人物也在今年稍早遭到逮捕。
在 macOS 上，勒索病毒會使用 osascript 來修改系統桌布，osascript 指令如下：
“tell application "System Events" to tell every desktop to set picture to "%s”
若是在 Windows 上，勒索病毒會呼叫 SystemParametersInfoW 並將 uiAction 參數設為 SPI_SETDESKWALLPAPER 來變更桌布。
在某些 Windows 樣本當中，我們還會找到一些刪除備份資料 (陰影複製) 的程式碼。有趣的是，勒索病毒開發者很可能在不知情的狀況下從一個勒索病毒模擬程式專案當中複製了「shadowcopy.go」檔案並留下了「/for」參數而未加以變更。
結論
駭客越來越常利用雲端服務和功能來從事惡意活動。在這篇部落格中，我們分析了一個使用 Amazon S3 Transfer Acceleration 傳輸加速功能將受害者檔案上傳到駭客掌控 S3 儲存貯體的 Golang 勒索病毒。這類進階功能可讓駭客在使用雲端服務供應商時，更有效率地竊取資料。
此外，雲端廠商的帳戶識別碼，例如與惡意活動相關的 AWS 帳號 ID，也可當成重要的入侵指標 (IoC)。藉由追蹤這些 ID，企業就能更有效發掘及防範其雲端環境內的威脅，而這也突顯出密切監控雲端資源的必要性。
此外，駭客還會偽裝成其他更廣為人知的勒索病毒，這原因不難理解：因為惡名昭彰的勒索病毒可以讓受害者備感壓力，因而屈服。
為了進一步提升資安，企業也可採用 Vision One 這類資安解決方案來及早偵測及攔截威脅，不論威脅在系統內何處。
AWS Security 的回覆
我們就這起事件聯絡了 AWS 並收到以下回覆：
AWS 可確認 AWS 的所有服務目前都正常運作。所發現的活動已違反了 AWS 的使用政策，而且所通報的 AWS 存取金鑰和帳號皆已被停用。
勒索病毒並非任何運算環境所獨有，不過，在針對惡意程式方面，AWS 為客戶提供了更好的資安狀況可視性與控管。
客戶若懷疑或知悉有 AWS 資源被用於可疑活動的狀況，請填寫濫用表單，或聯絡 trustandsafety@support.aws.com。
我們很感謝趨勢科技與 AWS Security 聯繫。
Trend Vision One 威脅情報
要隨時掌握持續演變的威脅，趨勢科技客戶可從 Trend Vision One 內部取得各種情報與威脅洞見。Threat Insights 可幫助客戶在威脅發生之前便提前掌握，並對新興的威脅預先做好準備。這些洞見提供了有關駭客、惡意活動及駭客技巧的完整資訊。善用這些情報，客戶就能主動採取步驟來保護自己的環境、防範風險，並且有效回應威脅。
Trend Vision One Intelligence Reports 應用程式 [IoC 掃描]
- LockBit 是假的、損害是真的：勒索病毒利用 AWS S3 竊取資料
Trend Vision One Threat Insights 應用程式
追蹤查詢
Trend Vision One 應用程式
Trend Vision One 客戶可以使用 Search 應用程式來尋找或追蹤本文提到的惡意指標，看看是否也出現在自己的環境中。
偵測 BOCKLIT 惡意程式是否存在：
malName:*BOCKLIT* AND eventName: MALWARE_DETECTION
除此之外，Vision One 客戶還可啟用 Threat Insights 權利來取得更多追蹤查詢。
入侵指標
在我們監控期間，我們看到這個勒索病毒有多個不同版本，它們全都具備加密功能，但只有某些具備上傳功能和有效的金鑰。這一點，再加上變種之間的其他差異，顯示勒索病毒仍在開發當中。
如需完整的入侵指標 (IoC) 清單，請至此處。