Azure 雲端環境中的攻擊防禦與檢測

知識 04-09

摘要

在我的文章《攻擊 Azure，Azure AD 及 PowerZure 介紹》中，我提供了幾種攻擊 Azure 和 AzureAD 的策略、技術和過程(TTPs) ，並發布了利用 PowerZure 來自動化操作其中的一些內容。我堅信，當一個新的戰術或工具開發出來後，防守指南應該遵循以幫助藍隊從這些戰術或工具中獲得安全感。不幸的是，Azure 對於發生在 Azure 內部的操作的日誌記錄能力還有很多不足之處。

本文的目的是對 Azure 內部的原生活動日誌服務功能進行概述，並深入探討如何檢測我上一篇文章中列出的許多 TTPs，以及關於如何從活動日誌服務中獲取更多細節的建議，而不僅僅是顯示在『 summary』選項卡上的內容。

概覽

每當一個操作在 Azure 中完成，一個事件就會生成並保存在活動日誌服務中。在活動日誌中，用戶可以看到所有操作並應用基本過濾器(時間跨度、嚴重性等)。日誌中的操作(事件)是根據操作的狀態分離出來的，即事件何時開始、何時更新、何時結束等等。為了查看該操作中的其他「子事件」，用戶必須單擊該事件，然後其他狀態事件將填充。這很重要，因為圍繞操作的細節取決於狀態。

圖1:單擊第一個事件會顯示一個子事件

例如，當一個用戶被分配到一個角色(例如 contributor)時，會啟動一個創建事件的操作，但是缺少必要的細節。

圖2:在Azure中為角色分配創建的初始事件

一旦操作完成，另一個「子事件」會被創建，然後公開必要的細節。

圖3:單擊子事件時會顯示更多的詳細信息

在本例中，「 Message」欄位包含添加到角色的用戶的用戶名，與不包含此信息的原始事件相比較。

警報

可以從活動日誌中直接配置警報。每當一個操作發生時，Azure 都會給出一個選項，一旦你點擊了這個事件，就可以為這個操作創建一個警報。

圖4:基於事件創建新警報的選項

在創建規則時，可以選擇更改條件。當保留默認條件時，它是一個非常常見的條件，如圖5所示：

圖5:條件被設置為成功的任何信息級的事件。這將產生幾個良性警報

條件可以通過點擊垃圾桶圖標和點擊條件下的「添加」來改變。

圖6: Runbooks的警報條件

從這裡，可以將警報操作設置為幾個選項。

圖7:警報選項

細節決定一切，是嗎？

獲取一個常規事件對於警報非常有用，但是對於分析人員來說，擁有與該事件相關的細節是非常關鍵的，比如誰開始了操作，操作的目標對象是什麼，等等。不幸的是，有幾個操作報告的細節信息很少。

命令執行

在虛擬機上運行命令時，會創建一個事件，但是沒有記錄運行的命令。

圖8:在VM上運行命令的事件中返回的所有內容

摘要選項卡顯示了命令的執行時間和執行者，但是為了查看執行時 VM 的名稱，用戶必須進入 JSON 選項卡並查看『 id』屬性才能查看事件的作用域。

圖9:作用域路徑中VM的名稱

無論何時向 Windows 虛擬機發出命令，Azure 都將輸入的命令作為 PowerShell 腳本存儲在內部端點上

C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows\1.1.3\Downloads

如果攻擊者沒有刪除腳本，這就允許分析人員可能看到在虛擬機上運行了哪些命令。當然，我總是建議你使用額外的防禦工具，並在組策略中對這些端點啟用腳本塊日誌記錄。

鑰匙庫

由於其用途，鑰匙庫在 Azure 中非常敏感。它們可以存儲證書、密碼和密鑰，因此它們也應該受到嚴密的訪問監控。進入鑰匙庫不會產生事件，也不會泄露密鑰。這就是這個資源與以角色為基礎的存取控制的預期目的; 就 Azure 而言，如果用戶訪問他們有權訪問的資源，它就不值得記錄事件。鑰匙庫僅限於其所有者，由所有者編輯訪問策略，允許其他用戶訪問該鑰匙庫。但是，作為全局參與者（Global Contributor），用戶可以編輯任何鑰匙庫的許可權並允許自己訪問該鑰匙庫。這確實會產生一個事件，「更新鑰匙庫」。

鑰匙庫更新時的日誌

事件摘要顯示了誰更新了保險庫的許可權，但是保險庫的名稱在 JSON 輸出中而不是摘要中。

圖10: JSON選項卡中的作用域顯示了庫名稱

這樣做的主要問題是，它沒有顯示誰被添加到訪問策略中。因此，確定誰被添加的唯一方法，就是進入每個保險庫並確定訪問策略上的所有用戶是否都應該在那裡。

Runbooks

在 PowerZure 中，一個利用 Runbook 優勢的函數是 Create-Backdoor。這是通過創建一個 Runbook 來實現的，該 Runbook 將提供一個新帳戶，並在執行時將其分配給 Contributor 角色。它不是自動執行，而是生成一個 Webhook URI，這個 URI 可以傳遞到 Execute-Backdoor，這個 Execute-Backdoor 將根據需要運行 Runbook。這需要管理員角色，因為只有管理員可以在 Azure AD 中創建用戶。幸運的是，創建 Runbook 會生成幾個事件，因此可以直接檢測這些事件。第一個關鍵事件，是創建 Runbook，然後創建 Webhook，然後生成該 Webhook 的 URI。

圖11: PowerZure中「 Create-Backdoor」的操作序列

這樣做的問題是，『event initiated by』欄位是不正確的。如果 Runbook 是從命令行創建的，則該欄位始終由租戶管理員(而不是實際創建 Runbook 的人)填充。為了確保我的頭腦清醒，我用三個不同的帳戶測試了它，每次事件由我的管理帳戶發起，即使它沒有登錄到任何地方。

圖12:由欄位啟動的事件顯示了通過CLI創建Webhook和Runbook時的租戶管理員，而不是實際用戶截止2020年1月24日，這個bug提交給微軟，我現在正在等待他們的回復。

分組任務

即使本地活動目錄(AD)與 AzureAD 同步，也不可能將用戶添加到本地 AD 組。然而，將用戶添加到 Azure 的 Azure 組中並不會在活動日誌下生成事件。 Azuread 有自己的事件查看器，稱為審計日誌。這確實提供了操作的必要細節，但是在 AzureAD 中不能為這些事件配置警報，除非正在使用 Log Analytics 服務，並且 AzureAD 被配置為向 Log Analytics 發送日誌。然後警報將不得不從日誌分析生成，而不是 AzureAD 的審計日誌。

虛擬機磁碟

如果攻擊者侵入了一個全局參與者（Global Contributor）的帳戶，他們可能會生成一個下載 VM 磁碟的鏈接。這可以通過操作名「獲取磁碟 SAS URI」檢測到。摘要或 JSON 選項卡中沒有顯示鏈接，磁碟是否實際下載也沒有顯示鏈接。只創建一個泛型事件，除了磁碟名之外沒有其他詳細信息。

防禦方法

由於 Azure 使用了以角色為基礎的存取控制訪問控制(RBAC) ，它應該被視為類似於本地 AD 組成員，這意味著它應該遵循最少特權訪問的方法。將 Global Contributor 角色分配給用戶可以為用戶提供大量的訪問和執行能力。建議檢查在 Azure 中哪些角色實際上是操作所必需的。 Azure 包含許多「全球」角色之外的內置角色，可以在這裡查看。此外，定製角色的創建可能更適合企業的需要。

遵循最低特權訪問的方法，Azure 確實提供了特權身份管理(Privileged Identity Management，PIM)服務，但是要付出一定的代價，但是我們強烈推薦這種服務。

組織希望盡量減少能夠訪問安全信息或資源的人數，因為這樣可以減少惡意行為者獲得該訪問許可權的機會，或者減少授權用戶無意中影響敏感資源的機會。然而，用戶仍然需要在 Azure AD、 Azure、 Office 365或 SaaS 應用程序中執行特權操作。組織可以向用戶提供對 Azure 資源和 Azure AD 的即時(JIT)特權訪問。有必要監督這些用戶使用管理員許可權所做的事情。 ——微軟

PIM 類似於特權訪問管理(Privileged Access Management，PAM)解決方案，它只在需要時提供管理或特權訪問。 PIM 可以在每個資源的基礎上使用。在 PIM 面板中，有三個類別: 合格的、活動的和過期的。「合格」意味著用戶可以請求訪問該資源上的該角色。活動意味著用戶主動擁有該角色並且不需要批准。過期意味著不再允許用戶請求對該角色的訪問，並且不再擁有該角色。

圖13: 『 Contrib』用戶允許請求對資源的contributor角色的訪問

例如，如果一個用戶為了一個虛擬機資源被添加到 PIM 中，並且有資格請求訪問 Contributor 角色，那麼該用戶只需要請求激活該虛擬機的特權，而不必為所有其他用戶這樣做。由於角色是層次化的，如果將 PIM 放在訂閱上，那麼它將影響該訂閱中的所有資源。使用 PIM，默認情況下不允許請求被批准。