應用程式同意授與調查

本文提供識別和調查應用程式同意攻擊、保護資訊，以及將進一步風險降至最低的指引。

本文包含下列章節：

• 必要條件： 涵蓋開始調查之前，您需要完成的特定需求。 例如，應該開啟的記錄、所需的角色和許可權等等。
• 工作流程： 顯示您應該遵循的邏輯流程，以執行此調查。
• 檢查清單： 包含流程圖中每個步驟的工作清單。 此檢查清單在高度管制的環境中很有説明，以驗證採取的步驟，或只是作為您自己的品質網關。
• 調查步驟： 包含此特定調查的詳細逐步指引。
• 復原： 包含如何從非法應用程式同意授與攻擊中復原/減輕的高階步驟。
• 參考： 包含更多閱讀和參考數據。

必要條件

以下是執行應用程式同意授與調查時應該完成的一般設定和組態。 開始調查之前，請確定閱讀同意許可權類型中所述 的同意許可權類型。

客戶資料

若要開始調查程式，您需要下列數據：

• 入侵指標的詳細資料（IoC）
• 您注意到事件的日期和時間
• 日期範圍
• 遭入侵的帳戶數目
• 遭入侵帳戶的名稱
• 遭入侵帳戶的角色
• 帳戶是否具有高度特殊許可權（GA Microsoft Exchange、SharePoint）？
• 是否有任何與事件相關的企業應用程式？
• 使用者是否報告任何代表其要求數據許可權的應用程式？

系統需求

請確定您已完成下列安裝和設定需求：

• 已安裝 AzureAD PowerShell 模組。
• 您在文稿執行的租使用者上具有 全域管理員 許可權。
• 您在用來執行文稿的電腦上獲指派本機系統管理員角色。

安裝 AzureAD 模組

使用此命令來安裝 AzureAD 模組。

Install-Module -Name AzureAD -Verbose

安裝 MSOnline PowerShell 模組

1. 以提升的許可權執行 Windows PowerShell 應用程式（以系統管理員身分執行）。

2. 執行此命令以允許 PowerShell 執行已簽署的腳本。

   Set-ExecutionPolicy RemoteSigned
   

3. 使用此命令安裝 MSOnline 模組。

   Install-Module -Name MSOnline -Verbose
   

   注意

   如果系統提示您從不受信任的存放庫安裝模組，請輸入 Y ，然後按 Enter。

從 GitHub 下載 AzureADPSPermissions 腳本

1. 將 Get-AzureADPSPermissions.ps1 腳本從 GitHub 下載到您執行腳本的資料夾。 輸出檔案 「permissions.csv」 也會寫入這個相同的資料夾。

2. 以系統管理員身分開啟 PowerShell 實例，然後開啟您儲存腳本的資料夾。

3. 使用 Connect-AzureAD Cmdlet 連線到您的目錄。 以下是範例。

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

4. 執行此 PowerShell 命令。

   Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation
   

   使用此命令中斷 AzureAD 會話的連線。

   Disconnect-AzureAD
   

同意術語

什麼是應用程式同意授與？

同意是將授權授與應用程式以代表使用者存取受保護資源的程式。 系統管理員可以要求系統管理員或使用者同意允許存取其組織/個人資料。

應用程式會根據特定用戶或整個組織授與數據存取權。 攻擊者可能會誤用這些同意來取得環境的持續性並存取敏感數據。 這些類型的攻擊稱為「非法同意授與」，這些攻擊可能透過網路釣魚電子郵件、用戶帳戶透過密碼噴洒入侵，或攻擊者將應用程式註冊為合法用戶時發生。 在系統管理員帳戶遭到入侵的情況下，註冊和同意授與適用於整個租使用者，而不只是針對一位使用者。

在應用程式可以存取貴組織的資料之前，使用者必須授與應用程式權限。 不同的權限允許不同的存取層級。 根據預設，所有使用者都能同意應用程式，從而取得不需要管理員同意的權限。 例如，根據預設，使用者可以同意允許應用程式存取其信箱，但無法同意允許應用程式不受限制地讀取和寫入組織中的所有檔案。

可以代表組織授與同意的角色

若要能夠授與 全租用戶的系統管理員同意，您必須使用至少下列其中一個角色登入：

• 應用程式系統管理員
• 雲端應用程式系統管理員

同意類型

• 系統管理員 - 表示系統管理員已提供同意（代表組織）
• 個別使用者 - 指出使用者已授與同意，且只能存取該用戶的資訊
• 接受的值
  • AllPrincipals - 由系統管理員同意整個租用
  • 主體 – 由個別使用者同意僅與該帳戶相關的數據

同意和權限

授與同意的實際用戶體驗會根據使用者租用戶上設定的原則、使用者的授權範圍（或角色）和用戶端應用程式所要求的許可權類型而有所不同。 這表示應用程式開發人員和租用戶管理員擁有相同的同意體驗控制權。 系統管理員有彈性地在租用戶或應用程式上設定和停用原則，以控制其租使用者的同意體驗。 應用程式開發人員可以決定要求的許可權類型，以及他們是否想要引導使用者通過使用者同意流程或系統管理員同意流程。

• 使用者同意流程 - 當應用程式開發人員將使用者導向授權端點時，意圖只記錄目前使用者的同意。

• 管理員同意流程 - 當應用程式開發人員將用戶導向管理員同意端點時，意圖記錄整個租使用者的同意。 為了確保管理員同意流程正常運作，應用程式開發人員必須在應用程式指令清單的 RequiredResourceAccess 屬性中列出所有許可權。

委派的許可權與應用程式許可權

具有登入使用者的應用程式會使用委派的許可權，而且可由系統管理員或使用者套用同意。

在沒有已登入使用者的情況下執行的應用程式會使用應用程式權限。 例如，以背景服務或精靈身分執行的應用程式。 應用程式許可權只能由系統管理員同意。

如需詳細資訊，請參閱

• 特定應用程式的系統管理員同意工作流程
• 發行者驗證程式
• 設定終端使用者同意應用程式的方式

分類具風險的許可權

系統中有數千個（至少）的許可權，無法列出或剖析所有這些許可權。 下列清單說明通常誤用的許可權，以及其他會在誤用時造成重大影響的其他人。

概括而言，Microsoft觀察到下列在同意網路釣魚攻擊中濫用的「根」委派（App+用戶）許可權。 根等於最上層。 例如，Contacts.* 表示包含聯繫人許可權的所有委派排列：Contacts.Read、Contacts.ReadWrite、Contacts.Read.Shared 和 Contacts.ReadWrite.Shared。

1. Mail.* （包括 Mail.Send*，但不包括 Mail.ReadBasic*）
2. 接觸。 *
3. MailboxSettings.*
4. 人。*
5. 檔案。*
6. 筆記。*
7. Directory.AccessAsUser.All
8. User_Impersonation

上一個清單中的前七個許可權適用於 Microsoft Graph 和「舊版」API 對等專案，例如 Azure Active Directory （Azure AD） Graph 和 Outlook REST。 第八個許可權適用於 Azure Resource Manager （ARM），而且對於任何公開敏感數據的 API 而言，也可能很危險，且此總管模擬範圍會公開敏感數據。

根據Microsoft事件回應小組的觀察，攻擊者會在同意網路釣魚攻擊的 99% 中使用前六個許可權的組合。 大多數人不會將 Mail.Read 或 Files.Read 的委派版本視為高風險許可權，不過，攻擊通常很普遍且以使用者為目標，而不是針對實際同意危險許可權的系統管理員進行魚叉式網路釣魚。 建議使用這些「重要」影響許可權層級來泡泡應用程式。 即使應用程式沒有惡意意圖，而且如果不良動作專案入侵應用程式身分識別，則整個組織可能面臨風險。

如需最高風險影響許可權，請從這裡開始：

• 適用時，所有上述許可權的應用程式許可權 （AppOnly/AppRole） 版本

委派和 AppOnly 版本的下列許可權：

• Application.ReadWrite.All
• Directory.ReadWrite.All
• Domain.ReadWrite.All*
• EduRoster.ReadWrite.All*
• Group.ReadWrite.All
• Member.Read.Hidden*
• RoleManagement.ReadWrite.Directory
• User.ReadWrite.All*
• User.ManageCreds.All
• 允許寫入存取權的所有其他 AppOnly 許可權

如需最低風險影響許可權清單，請從這裡開始：

• User.Read
• User.ReadBasic.All
• Open_id
• Email
• 設定檔
• Offline_access （只有在與這個「最低風險」清單的其他許可權配對時）

檢視權限

1. 若要檢視許可權，請瀏覽至企業應用程式中的 [ 註冊 ] 畫面。

   

2. 選取 [ 檢視 API 許可權]。

   

3. 選取 [新增許可權 ]，並顯示下列畫面。

   

4. 選取 [Microsoft Graph ] 以檢視不同類型的許可權。

   

5. 選取已註冊應用程式使用的許可權類型：委派的許可權或應用程式許可權。 在上圖中， 已選取 [應用程式許可權 ]。

6. 您可以搜尋其中一個高風險影響許可權，例如 EduRoster。

   

7. 選取 [EduRoster ]，然後展開許可權。

   

8. 您現在可以指派或檢閱這些許可權。

   如需詳細資訊， 請取得圖形許可權。

工作流程

[]

您也可以：

• 將應用程式同意授與和其他事件回應劇本工作流程下載為 PDF。
• 下載應用程式同意授與和其他事件回應劇本工作流程作為 Visio 檔案。

檢查清單

使用此檢查清單來執行應用程式同意授與驗證。

• 入侵指標 （IoC）

  檢查下列入侵指標 （IoC）：

  • 您何時注意到這一事件？
  • 事件的日期範圍（目標職位還有多遠？
  • 遭入侵的帳戶數目
  • 遭入侵帳戶的名稱
  • 遭入侵帳戶的角色
  • 遭入侵的帳戶是否具有高度特殊許可權、標準用戶或組合

• 角色

  您必須使用這些角色來指派：

  • 您執行文稿之電腦上的本機系統管理員角色

• PowerShell 組態

  使用下列步驟設定 PowerShell 環境：

  1. 安裝 Azure AD PowerShell 模組。
  2. 使用提升的許可權執行 Windows PowerShell 應用程式。 （以系統管理員身分執行）。
  3. 設定 PowerShell 以執行已簽署的腳本。
  4. 下載 Get-AzureADPSPermissions.ps1 腳本。

• 調查觸發程式

  • 帳戶入侵
  • 在租使用者上修改的應用程式同意設定
  • 偵測到「有風險的應用程式」的警示/稽核事件狀態原因
  • 注意到奇怪的應用程式

您也可以將應用程式同意授與和其他事件劇本檢查清單下載為 Excel 檔案。

調查步驟

您可以使用下列兩種方法來調查應用程式同意授與：

• Azure 入口網站
• PowerShell 指令碼

方法 1 – 使用 Azure 入口網站

您可以使用 Microsoft Entra 系統管理中心來尋找個別使用者已授與許可權的應用程式。

1. 以系統管理員身分登入 Azure 入口網站。
2. 選取Microsoft 項目標識符 圖示。
3. 選取使用者。
4. 選取您要檢閱的使用者。
5. 選取應用程式。
6. 您可以看到指派給使用者的應用程式清單，以及這些應用程式具有哪些許可權。

方法 2 - 使用 PowerShell

有數種 PowerShell 工具可用來調查非法同意授與，例如：

• HAWK 工具
• AzureAD 事件回應模組
• 來自 GitHub 的 Get-AzureADPSPermissions.ps1 腳本

PowerShell 是最簡單的工具，不需要您在租用中修改任何專案。 我們將根據非法同意授權攻擊的公開文件進行調查。

執行 Get-AzureADPSPermissions.ps1，將租使用者中所有使用者的所有 OAuth 同意授與和 OAuth 應用程式導出至 .csv 檔案。 請參閱必要條件一節，以下載並執行Get-AzureADPSPermissions腳本。

1. 以系統管理員身分開啟 PowerShell 實例，然後開啟您儲存腳本的資料夾。

2. 使用下列 Connect-AzureAD 命令連線到您的目錄。 以下是範例。

   Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"
   

3. 執行此 PowerShell 命令。

   Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation
   

4. 腳本完成之後，建議您使用此命令中斷Microsoft Entra 會話的連線。

    Disconnect-AzureAD
   

   注意

   視設定的大小和許可權以及連線而定，腳本可能需要數小時才能完成。

5. 腳本會建立名為 Permissions.csv 的檔案。

6. 開啟檔案，然後將數據篩選或格式化為數據表，然後儲存為 .xlxs 檔案。

   輸出 的數據 行標頭會顯示在此影像中。

   

7. 在 ConsentType 資料行 （G） 中，搜尋 AllPrinciples 值。 AllPrincipals 許可權可讓用戶端應用程式存取租用中每個人的內容。 原生Microsoft 365 應用程式需要此許可權才能正常運作。 應仔細檢閱具有此許可權的每個非Microsoft應用程式。

8. 在 [ 許可權] 資料 行 （F）中，檢閱每個委派應用程式擁有的許可權。 尋找 讀取 和 寫入 許可權或 *。所有 許可權，並仔細檢閱這些許可權，因為它們可能不適合。

   注意

   檢閱已授與同意的特定使用者。 如果高調或高影響使用者授與不當同意，您應該進一步調查。

9. 在 ClientDisplayName 資料行 （C）中，尋找看似可疑的應用程式，例如：

   • 名稱拼錯的應用程式

   • 不尋常的或平淡的名稱

   • 駭客聽起來的名字。 您必須仔細檢閱這些名稱。

範例輸出： AllPrincipals 和 read write all。 應用程式可能沒有任何可疑專案，例如平淡的名稱，而且正在使用 MS 圖形。 不過，請執行研究並判斷應用程式在租用戶中擁有的實際許可權，如此範例所示。

以下是檢閱資訊安全策略 （ISP） 調查的一些實用秘訣：

• ReplyURL/RedirectURL
  • 尋找可疑的URL
• URL 是否裝載在可疑網域上？
  • 是否遭到入侵？
  • 網域最近是否已註冊？
  • 這是暫存網域嗎？
• 應用程式註冊中是否有服務/服務合約連結？
• 內容是否是唯一且專屬於應用程式/發行者？
• 新建立或遭入侵的租使用者是否已註冊應用程式（例如，由有風險的用戶註冊應用程式）？

同意授與攻擊的詳細數據

攻擊技術

雖然 每個攻擊通常會有所不同，但核心攻擊技術如下：

• 攻擊者向 OAuth 2.0 提供者註冊應用程式，例如Microsoft Entra ID。

• 應用程式會以使其看起來合法的方式進行設定。 例如，攻擊者可能會使用相同的生態系統中可用的熱門產品名稱。

• 攻擊者直接從使用者取得連結，這些連結可能透過傳統電子郵件型網路釣魚、入侵非惡意網站或其他技術來完成。

• 用戶選取連結，並顯示正宗同意提示，要求他們授與惡意應用程式數據的許可權。

• 如果使用者選取 [接受]，則會授與應用程式存取敏感數據的許可權。

• 應用程式會取得授權碼，其會兌換存取令牌，以及可能重新整理令牌。

• 存取令牌是用來代表用戶進行 API 呼叫。

• 如果使用者接受，攻擊者就可以存取使用者的郵件、轉寄規則、檔案、聯繫人、筆記、配置檔和其他敏感數據和資源。

  

尋找攻擊的跡象

1. 在 位於 的 Microsoft 365 Defender 入口網站 https://security.microsoft.com中，移至 [ 稽核]。 或者，若要直接移至 [ 稽核 ] 頁面，請使用 https://security.microsoft.com/auditlogsearch。

2. 在 [ 稽核 ] 頁面上，搜尋所有活動和所有使用者，視需要輸入開始日期和結束日期，然後選取 [ 搜尋]。

   

3. 選取 [ 篩選結果] ，然後在 [ 活動 ] 字段中輸入 [同意 應用程式]。

   

4. 如果您有同意授與的活動，請繼續進行下一個步驟。

5. 選取結果以查看活動的詳細數據。 選取 [詳細資訊 ] 以取得活動的詳細數據。

6. 檢查IsAdminContent是否設定為 『True』。

   注意

   此程式可能需要 30 分鐘到 24 小時的時間，對應的稽核記錄專案才會在事件發生后顯示在搜尋結果中。

   稽核記錄保留的時間範圍，且可在稽核記錄中搜尋，取決於您的Microsoft 365 訂閱，特別是指派給特定用戶的授權類型。 如果此值為 true，表示某人可能已授與廣泛數據存取權。 如果這是非預期的，請立即採取步驟來確認攻擊。

如何確認攻擊？

如果您有一或多個先前列出的IoC實例，您必須進行進一步調查，以積極確認發生攻擊。

清查組織中具有存取權的應用程式

您可以使用 Microsoft Entra 系統管理中心、PowerShell，或讓使用者個別列舉其應用程式存取權，為您的使用者清查應用程式。

• 使用 Microsoft Entra 系統管理中心來清查應用程式和其許可權。 這個方法是徹底的，但您一次只能檢查一個使用者，如果您必須檢查數個用戶的許可權，這很耗時。
• 使用 PowerShell 清查應用程式及其許可權。 此方法是最快速且最徹底的，且額外負荷最少。
• 鼓勵使用者個別檢查其應用程式和許可權，並將結果回報給系統管理員以進行補救。

指派給使用者的清查應用程式

您可以使用 Microsoft Entra 系統管理中心來查看個別使用者授與許可權的應用程式清單。

1. 使用系統管理許可權登入 Azure 入口網站 。
2. 選取Microsoft 項目標識符 圖示。
3. 選取使用者。
4. 選取您要檢閱的使用者。
5. 選取應用程式。

您可以看到指派給使用者的應用程式清單，以及授與這些應用程式的許可權。

判斷攻擊的範圍

完成清查應用程式存取之後，請檢閱稽核記錄，以判斷缺口的完整範圍。 搜尋受影響的使用者、非法應用程式可存取您組織的時間範圍，以及應用程式擁有的許可權。 您可以在 Microsoft 365 安全性與 Microsoft Purview 合規性入口網站 中搜尋稽核記錄。

如何防止攻擊並降低風險？

• 定期 稽核您組織中的應用程式和 授與許可權，以確保不會授與任何不必要或可疑的應用程式存取數據。

• 在 Office 365 中檢閱、偵測及補救非法同意授權。 如需更多最佳做法，並防範要求 OAuth 同意的可疑應用程式。

若您組織擁有適當的授權：

• 在 適用於雲端的 Microsoft Defender Apps 中使用更多 OAuth 應用程式稽核功能。
• 使用 Azure 監視器活頁簿 來監視許可權和同意相關活動。 同意深入解析活頁簿會依失敗的同意要求數目來提供應用程式的檢視。 這有助於排定應用程式優先順序，讓系統管理員檢閱及決定是否要授與系統管理員同意。

如何停止和補救非法同意授與攻擊？

識別具有非法許可權的應用程式之後， 請依照停用應用程式 中的 指示立即停用應用程式。 然後，請連絡 Microsoft 支援服務 報告惡意應用程式。

Microsoft Entra 中停用應用程式之後，就無法取得存取數據的新令牌，而其他使用者無法登入或授與應用程式同意。

建議的防禦

保護組織的步驟

有各種同意攻擊類型，這些建議的防禦可減輕所有類型的攻擊，特別是同意網路釣魚，其中攻擊者會誘使用戶授與惡意應用程式對敏感數據或其他資源的存取權。 攻擊者不會嘗試竊取使用者的密碼，而是尋求攻擊者控制應用程式存取寶貴數據的許可權。

若要協助防止同意攻擊影響 Microsoft Entra ID 和 Office 365，請參閱下列建議：

設定原則

• 此設定具有使用者含意，可能不適用於環境。 如果您要允許任何同意，請確定系統管理員核准要求。

• 只允許來自已驗證發行者的應用程式同意，以及分類為低影響的特定許可權類型。

  注意

  根據最理想的安全設定，建議上述建議。 不過，由於安全性在功能和作業之間是一個精細的平衡，因此最安全的設定可能會對系統管理員造成更多額外負荷。 這是與系統管理員諮詢后做出的最佳決策。

  設定風險型逐步同意 - 啟用使用者同意授與時默認啟用

• 以風險為基礎的升級同意有助於降低使用者暴露於進行非法同意要求的惡意應用程式風險。 如果Microsoft偵測到有風險的終端使用者同意要求，要求會改為要求管理員同意。 此功能預設為啟用，但只有在啟用使用者同意時，才會造成行為變更。

• 偵測到有風險的同意要求時，同意提示會顯示訊息，指出需要管理員核准。 如果已啟用管理員同意要求工作流程，使用者可以直接從同意提示將要求傳送給系統管理員，以便進一步檢閱。 如果已啟用，會顯示下列訊息：

  AADSTS90094： <clientAppDisplayName> 需要許可權，才能存取組織中只有系統管理員可以授與的資源。 請先要求系統管理員授與此應用程式的許可權，才能使用它。 在此情況下，稽核事件也會記錄為「同意應用程式」的「ApplicationManagement」活動類型類別，以及「偵測到具風險的應用程式」狀態原因。

教育您的應用程式開發人員遵循值得信任的應用程式生態系統。 為了協助開發人員建置高品質且安全的整合，我們也在 Microsoft Entra 應用程式註冊中宣佈 整合小幫手的公開預覽。

• Integration Assistant 會分析您的應用程式註冊，並針對一組建議的安全性最佳做法進行基準檢驗。
• 整合小幫手會強調整合生命週期中每個階段相關的最佳做法，從開發到監視，並確保每個階段都已正確設定。
• 無論您要整合第一個應用程式，還是想要改善技能的專家，它都會讓您的工作變得更容易。

教育貴組織同意策略（網路釣魚策略、系統管理員和使用者同意 ）：

• 檢查是否有不良的拼寫和文法。 如果電子郵件訊息或應用程式的同意畫面有拼字和文法錯誤，可能是可疑的應用程式。
• 請留意應用程式名稱和網域URL。 攻擊者喜歡詐騙應用程式名稱，使其似乎來自合法應用程式或公司，但會促使您同意惡意應用程式。
• 在同意應用程式之前，請務必先辨識應用程式名稱和網域URL。

升級並允許存取您信任的應用程式

• 升級發行者驗證的應用程式使用。 發行者驗證可協助系統管理員和使用者瞭解應用程式開發人員的真實性。 到目前為止，超過 660 個應用程式由 390 個發行者驗證。
• 設定應用程式同意原則，方法是允許使用者只同意您信任的特定應用程式，例如由組織開發的應用程式，或從已驗證的發行者開發的應用程式。
• 教育貴組織關於我們的許可權和同意 架構的運作方式。
• 瞭解應用程式要求的數據和許可權，並瞭解許可權和同意在我們的平台中運作的方式。
• 請確定系統管理員知道如何管理和評估同意要求。

稽核您組織中的應用程式和同意的許可權，以確保使用的應用程式只會存取所需的數據，並遵守最低許可權的原則。

風險降低

• 教育客戶並提供保護應用程式同意授與的認知和訓練
• 使用組織原則和技術控制來加強應用程式同意授與程式
• 設定建立 排程 以檢閱 同意 的應用程式
• 您可以藉由 停用應用程式，使用 PowerShell 來停用可疑或惡意的應用程式

相關內容

• 保護遠端員工應用程式攻擊
• 促進安全且值得信任的應用程式生態系統
• 調查有風險的 OAuth 應用程式
• 管理對應用程式的同意並評估同意要求
• 在 entra 識別碼中停用企業應用程式的使用者登入Microsoft
• 了解 Microsoft 身分識別平台的權限和同意架構。
• 了解委派權限與應用程式權限之間的差異。
• 設定使用者同意應用程式的方式
• 我的應用程式清單中的非預期應用程式
• 偵測並補救非法同意授權
• 新增Microsoft Entra 應用程式的方式和原因
• Microsoft Entra 中的應用程式和服務主體物件 (機器翻譯)
• Microsoft Entra Config Documentor
• 管理對應用程式的同意並評估同意要求
• Get-AzureADServicePrincipal
• 組建 2020：為所有用戶培養安全且值得信任的應用程式生態系統
• 設定管理員同意工作流程
• 系統管理員應該先仔細評估所有同意要求，再核准要求。
• 應用程式註冊與企業應用程式
• 權限
• AppConsent 網路釣魚上的 KrebsOnSecurity

其他事件回應劇本

檢查識別和調查這些額外攻擊類型的指引：

• 網路釣魚
• 密碼噴灑

事件回應資源

• 適用於新角色和經驗豐富的分析師Microsoft安全性產品和服務的概觀
• 規劃 您的安全性作業中心 （SOC）
• Microsoft Defender 全面偵測回應 事件回應
• 適用於雲端的 Microsoft Defender （Azure）
• Microsoft Sentinel 事件回應
• Microsoft事件回應小組指南會分享安全性小組和領導者的最佳做法
• Microsoft事件回應指南可協助安全性小組分析可疑活動