開發者工具 · Base64 編碼器和解碼器
如何在不運作的情況下解碼可疑的 Base64 PowerShell 指令
· 為什麼它很重要
base64 安全
攻擊者使用 Base64 隱藏腳本以防止隨意檢查。這篇文章展示瞭如何解碼 -EncodedCommand 有效負載而不執行它，為什麼輸出在 UTF-8 解碼器中看起來很奇怪，以及要尋找什麼。
帶有 2,000 字元參數的計畫任務 — 編碼指令出現的位置以及為什麼它們是危險訊號
系統管理員發現計畫任務帶有看起來可疑的 2,000-character -EncodedCommand 參數。該任務在具有高權限的服務帳戶下執行。
將命令貼到 PowerShell 中並執行它以查看其功能的誘惑是危險的；如果該命令是惡意的，執行它會危及系統。更安全的方法是在本機解碼 Base64 並以文字形式讀取輸出，然後再決定是否要執行任何內容。這篇文章解釋瞭如何安全地解碼 PowerShell 命令而不執行它們，為什麼輸出在標準 UTF-8 解碼器中可能看起來亂碼，以及如何尋找來評估命令是安全還是可疑。
解碼，從不執行 - 確保分析安全的規則，以及為什麼僅瀏覽器解碼器非常適合
關鍵的見解是 PowerShell 對 -EncodedCommand 使用 UTF-16LE 編碼，而不是 UTF-8，因此每隔一個位元組都是零，標準工具將其解釋為空終止符。分析任何可疑程式碼的規則很簡單：解碼，從不執行。這適用於 Base64 編碼的命令、壓縮腳本、來自不受信任來源的腳本以及不熟悉的編碼鏈中的任何內容。執行腳本就沒有回頭路了；一旦它執行，系統就會發生變化，存取權限就會被授予，資料也會被洩露。
將腳本解碼並作為文字讀取可以讓您在不可逆步驟之前對其進行評估。第二條規則是使用本地執行且不發出網路請求的工具。基於瀏覽器的解碼器是理想的選擇，因為它是便攜式的，不需要額外的軟體，並可以將可疑的有效負載保留在您的裝置上，而無需將其上傳到任何伺服器。如果該工具是發佈到遠端解碼器服務的工具，請不要使用它；然後將有效負載暴露給該服務。 PowerShell -EncodedCommand 參數接受 Base64 字串，該字串在解碼後包含 PowerShell 腳本。
為什麼解碼後的位元組看起來不像 UTF-8 文字 - 檢查十六進位的 UTF-16LE 位元組模式，而不是要求這個 UTF-8 文字工具來解釋它
然而，PowerShell 並未為此使用 UTF-8 編碼；它使用 UTF-16LE（小端 UTF-16）。在 UTF-16 中，每個 ASCII 字元都表示為兩個位元組：字元代碼後面接著一個零位元組。字母 A 的十六進位表示為 41 00。字母 B 是 42 00。像 Hello 這樣的字串在 UTF-16LE 位元組中顯示為 48 00 65 00 6C 00 6C 00 6F 00。當這是 Base64 編碼時，結果包含所有這些位元組的編碼形式，包括所有零。使用標準 UTF-8 解碼器進行解碼會產生亂碼文字或在第一個零位元組處截斷，因為 UTF-8 將空位元組視為字串終止符。
輸出看起來像 H e l o 而不是 Hello，帶有看似隨機的字元或缺失文字。一個有效的例子展示了問題和解決方案。假設 PowerShell 指令對簡單字串 Write-Host Hello 進行編碼。 PowerShell UTF-16LE 將此位元組編碼為包含所有零的位元組，Base64 編碼位元組並產生一個長字串，例如 VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA。將此字串複製到瀏覽器中的 Base64 編碼器和解碼器中，然後按一下「解碼」。預設解碼器將嘗試將結果解釋為 UTF-8 文字，並由於嵌入的零而產生損壞或截斷的輸出。
工作範例：解碼無害的範例編碼命令 - 讀取交錯零位元組之後的文字
解決方案是使用十六進制視圖。切換到十六進位視圖，您會看到位元組： 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 0064 00 6C 22 00. 將這些位元組作為 UTF-16LE 對讀取會產生 W-r-i-t-e---K-o-s-h---H-e-l-l-o-。憑藉經驗，您可以直接讀取 UTF-16LE 十六進制，也可以將位元組寫入檔案並使用本地執行的 PowerShell 或 Python 腳本對其進行解碼。
實用的方法是記下該模式並記住 PowerShell 使用 UTF-16LE。當您在瀏覽器中解碼 PowerShell -EncodedCommand 並輸出看起來錯誤時，請查看十六進位視圖而不是文字視圖。十六進位視圖單獨顯示每個位元組。每個 ASCII 字元均顯示為兩個位元組，中間有一個零。如果這些位元組拼出惡意命令，例如 New-AdminAccount、反向 DNS 查找或匯出安全性憑證，則該命令是可疑的。如果這些位元組拼出一些無害的內容，例如目錄清單或簡單腳本，則該命令可能是良性的。
嵌套編碼和壓縮 - Base64 內部的 Base64，以及無法讀取為文字的 gzip 串流
十六進位視圖比純文字更難閱讀，但比從損壞的 UTF-8 輸出中猜測更安全。巢狀編碼和壓縮增加了惡意軟體分析的複雜性。 PowerShell 指令可能會對另一個 Base64 字串進行 Base64 編碼，或使用 gzip 壓縮腳本，然後對結果進行 Base64 編碼。在嵌套場景中，您解碼外部 Base64，讀取結果並發現它本身就是 Base64。也對其進行解碼並繼續，直到找到可讀文字或無法解釋的二進位格式。 Gzip 和其他壓縮格式以十六進位視圖中可見的魔術位元組（gzip 為 1F 8B）開頭。
如果解碼 Base64 且十六進位視圖以 1F 8B 開頭，則位元組是需要解壓縮的壓縮流。 Base64 編碼器和解碼器會向您顯示十六進位，幫助您識別這些模式而不執行任何操作。壓縮或進一步編碼的有效負載是可疑的，因為它們添加了混淆層。
事件報告要記錄的內容 - 解碼文字、來源和雜湊值，而不是有效負載本身
合法的命令很少需要多個編碼步驟。記錄事件報告的結果需要紀律和準確性。記下您分析的確切 Base64 字串、找到它的位置和時間。如果您對其進行解碼並發現可疑命令，請描述這些命令，但不要在報告中包含完整的腳本；腳本可能很複雜或很長。
包含已解碼腳本的雜湊值 (SHA-256)，以便可以驗證和追蹤結果。如果該命令明顯是惡意的或使用已知的利用技術，請在採取任何行動之前讓事件回應和安全團隊參與。切勿親自執行該命令來查看它的作用。如果事件回應人員需要執行它進行測試，他們會在包含任何損壞的沙盒環境中執行此操作。您的工作是在安全距離內解碼和評估風險。本文不涵蓋惡意軟體分析、沙箱環境或攻擊歸因的全部範圍。
這不包括沙箱執行、惡意軟體分析工具和歸因
這些是安全專業人員和事件響應團隊的主題。這裡的範圍主要集中在安全地解碼編碼的 PowerShell 命令而不執行它，因此您可以閱讀該腳本並評估它是否值得進一步研究。 Base64 編碼是混淆，而不是保護。任何擁有編碼和解碼器的人都可以提取腳本。攻擊者使用 Base64 來逃避基本偵測並防止隨意檢查，而不是隱藏其意圖以防止分析。獲取並执行遠程脚本的已解碼 PowerShell 命令是恶意的，無论您自己解碼还是安全工具解碼。
解碼可疑命令後實際的下一步是將其報告給適當的團隊。如果是您自己的系統，請確定該任務是否是有意創建的以及由誰創建的。檢查建立日期和安排它的帳戶。如果該任務未經授權，請將其停用，保留詳細資訊以供取證，並調查攻擊者如何獲得創建它的權限。如果该命令包含網絡请求或持久性机制（例如注册表更改或計划任務创建），則几乎可以肯定它是恶意的。
重點：Base64 是混淆，而不是保護 — Base64 編碼器和解碼器如何在本地解碼有效負載，而無需離開您的機器
如果它執行合法的管理功能並創建詳細資訊正常，則它可能是合法的管理腳本，恰好由於與安全策略或與更大的自動化工具整合相關的原因而被編碼。無論哪種方式都不要執行；讓您對解碼文字的評估告知您的決定。可疑 Base64 PowerShell 命令的安全解碼遵循一個簡單的過程。使用 Base64 編碼器和解碼器來解碼字串，而無需上傳或執行任何操作。查看十六進制視圖以了解位元組代表什麼。
如果您看到 UTF-16LE 模式（交錯的零字節），请記住 PowerShell 使用 UTF-16LE 並进行相應讀取。識別任何可疑模式，例如網路請求、特權提升或持久性機制。準確記錄事件報告的詳細信息，包括原始 Base64 字串及其雜湊值。切勿自行执行该命令；將其留給受控環境中的事件響應人員。相信您的本地解碼和對明文的評估，並讓它指導您的下一步。