共用方式為


遭入侵及惡意應用程式的調查

本文提供識別和調查客戶租使用者中一或多個應用程式的惡意攻擊的指引。 逐步指示可協助您採取必要的補救動作來保護資訊,並將進一步的風險降到最低。

  • 必要條件: 涵蓋開始調查之前,您需要完成的特定需求。 例如,應該開啟的記錄、所需的角色和權限等等。
  • 工作流程: 顯示您應該遵循的邏輯流程,以執行此調查。
  • 調查步驟: 包含此特定調查的詳細逐步指引。
  • 限制步驟: 包含如何停用被入侵應用程式的步驟。
  • 復原步驟: 包含如何從遭入侵應用程式的惡意攻擊中復原/緩解的高階步驟。
  • 參考: 包含其他讀取和參考數據。

必要條件

開始調查之前,請確定您有正確的工具和許可權可收集詳細資訊。

必要工具

若要進行有效的調查,請在您的調查計算機上安裝下列 PowerShell 模組和工具組:

工作流程

調查步驟的詳細流程圖。

調查步驟

針對此調查,假設您有用戶報告形式的潛在應用程式入侵指示、Microsoft Entra 登入記錄的範例或身分識別保護偵測。 請務必完成並啟用所有必要的必要步驟。

此劇本的建立目的是並非所有Microsoft客戶及其調查小組都有完整的 Microsoft 365 E5 或 Microsoft Entra ID P2 授權套件可供使用或設定。 在適當時,此指南會強調其他自動化功能。

決定應用程式類型

請務必在調查階段早期判斷應用程式類型(多租使用者或單一租使用者),以取得與應用程式擁有者連絡所需的正確資訊。 如需詳細資訊,請參閱 Microsoft Entra ID 中的租用戶

多租用戶應用程式

對於多租使用者應用程式,應用程式是由第三方裝載和管理。 識別連絡並回報問題給應用程式擁有者的流程。

單一租戶應用程式

尋找組織內應用程式擁有者的聯繫人詳細數據。 您可以在 [企業應用程式] 區段的 [擁有者] 索引標籤下找到它。 或者,您的組織可能有具有這項信息的資料庫。

您也可以執行此Microsoft Graph 查詢:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

檢查身份識別保護 - 風險性工作負載身份識別

此功能在撰寫此劇本時處於預覽狀態,且授權需求適用於其使用方式。 具風險的工作負載身分識別可以是調查服務主體的觸發點,且也可用來進一步調查您已識別的其他觸發點。 您可以使用 Identity Protection - 具風險的工作負載身分識別 標籤來檢查 服務主體 的風險狀態,或者您可以使用 Microsoft Graph API。 您也可以使用自然語言提示,透過 Microsoft Entra中的 Microsoft 安全 Copilot 來取得風險工作負載身分的深入見解。

風險偵測詳細數據入口網站頁面的螢幕快照。

風險偵測詳細數據使用者介面頁面的螢幕快照。

服務主體風險偵測圖形 API 的範例。

檢查不尋常的登入行為

調查的第一個步驟是尋找服務主體使用方式中異常驗證模式的證據。 在組織選擇的 Azure 入口網站、Azure 監視器、Microsoft Sentinel 或組織選擇的安全性資訊和事件管理 (SIEM) 系統中,尋找服務主體登入一節中的下列內容:

  • 位置 - 服務主體是否從您預期的位置\IP 位址進行驗證?
  • 失敗 - 服務主體是否有大量驗證失敗?
  • 時間戳記 - 是否有在您意想不到的時間發生的成功驗證?
  • 頻率 - 服務主體的驗證頻率是否增加?
  • 外洩認證 - 是否有任何應用程式認證硬式編碼,並在 GitHub 之類的公用來源上發佈?

如果您已部署Microsoft Entra ID Identity Protection - 具風險的工作負載身分識別,請檢查 可疑的登入和認證外洩偵測。 如需詳細資訊,請參閱 工作負載身分識別風險拘留

檢查目標資源

在服務主體登入內,也請檢查服務主體在驗證時存取的資源。 請務必從應用程式擁有者取得輸入,因為它們熟悉服務主體應該存取哪些資源。

檢查服務主體資源的方法截圖。

檢查認證變更異常

使用稽核記錄來取得應用程式和服務主體認證變更的相關信息。 依應用程式管理篩選類別,並依更新應用程式 – 憑證和秘密管理篩選活動。

  • 檢查是否有新建立或未預期的憑證分配給服務主體。
  • 使用 Microsoft Graph API 檢查服務主體上的認證。
  • 檢查應用程式和相關聯的服務主體物件。
  • 檢查您所建立或修改的任何 自定義角色 。 請注意下列標示的權限:

如何檢查已建立或已修改之自定義角色的螢幕快照。

如果您在 適用於雲端的 Microsoft Defender Apps 中部署應用程式控管,請檢查 Azure 入口網站 是否有與應用程式相關的警示。 如需詳細資訊,請參閱 開始使用應用程式威脅偵測和補救

如果您已部署 Identity Protection,請檢查「風險偵測」報告,並在使用者或工作負載身分識別中檢查「風險歷程記錄」。

風險偵測入口網站用戶介面的螢幕快照。

如果您已部署 Microsoft Defender for Cloud Apps,請確保已啟用「憑證異常新增至 OAuth 應用程式」原則,並檢查看看是否有任何開啟的警示。

如需詳細資訊,請參閱 OAuth 應用程式中憑證的異常新增

此外,您可以查詢 servicePrincipalRiskDetections 和使用者風險偵測 API 來擷取這些風險偵測。

搜尋異常應用程式組態變更

  • 檢查指派給應用程式的 API 許可權,以確保許可權與應用程式預期的許可權一致。
  • 檢查稽核記錄(依更新應用程式更新服務主體篩選活動)。
  • 確認 連接字串 是否一致,以及是否已修改註銷 URL。
  • 確認 URL 中的網域是否與已註冊的網域一致。
  • 判斷是否有人新增未經授權的重新導向 URL。
  • 請確認您擁有的重新導向 URI 的擁有權,以確保它沒有過期並被不當使用者取得。

此外,如果您已部署 適用於雲端的 Microsoft Defender Apps,請檢查 Azure 入口網站,以取得與您目前正在調查的應用程式相關的警示。 並非所有警示原則預設都會針對 OAuth 應用程式啟用,因此請確定這些原則全都已啟用。 如需詳細資訊,請參閱 OAuth 應用程式原則。 您也可以在 [調查>OAuth 應用程式] 索引標籤下檢視應用程式普及率和最近活動的相關信息。

檢查可疑的應用程式權限

  • 您也可以使用稽核記錄。 依將應用程式角色指派新增至服務主體篩選活動
  • 確認指派的角色是否具有高權限。
  • 確認是否需要這些許可權。

檢查未驗證的商業應用程式

  • 檢查是否使用商業圖庫(已發佈和已驗證的版本)應用程式。

檢查有關金鑰憑證屬性資料洩漏的跡象

檢閱您的租使用者,根據 CVE-2021-42306 所述,查看有無潛在的 keyCredential 屬性資訊洩漏。

若要識別並補救與受影響的自動化執行身分帳戶相關聯的受影響 Microsoft Entra 應用程式,請瀏覽至 補救指引 GitHub 存放庫

重要

如果您發現妥協的證據,請務必採取控制措施和復原步驟中所提及的步驟。 這些步驟有助於解決風險,但應進一步調查以瞭解威脅來源,從而避免進一步的影響,並確保移除惡意分子。

有兩個主要方法可透過使用應用程式來存取系統。 涉及的第一起事件是系統管理員或使用者同意了某個應用程式,通常是在網路釣魚攻擊的情況下。 此方法是系統初始存取的一部分,通常稱為「同意網路釣魚」。

第二種方法涉及已遭入侵的系統管理員帳戶,以建立新的應用程式,以便持續、數據收集及留在雷達下。 例如,遭入侵的系統管理員可以使用看似無害的名稱來建立OAuth 應用程式,避免偵測並允許長期存取數據,而不需要帳戶。 這種方法經常出現在國家/地區攻擊中。

以下是一些可以進一步調查的步驟。

檢查 Microsoft 365 統一稽核記錄(UAL)在過去 7 天內是否有網路釣魚跡象。

有時候,當攻擊者使用惡意或遭入侵的應用程式作為持續存在或資料外洩的手段時,可能涉及網路釣魚活動。 根據先前步驟的結果,您應該檢閱下列的身份:

  • 應用程式擁有者
  • 授權管理員

檢閱身分識別,以取得過去 24 小時內網路釣魚攻擊的指示。 如有需要,請將此時間範圍增加到 7、14 和 30 天,如果沒有立即指示。 如需網路釣魚調查劇本的詳細資訊,請參閱網路釣魚調查劇本

搜尋過去七天的惡意應用程式授權同意

若要讓應用程式新增至租用戶,攻擊者會詐騙使用者或系統管理員同意應用程式。 若要深入瞭解攻擊的跡象,請參閱 應用程式同意授與調查劇本

檢查稽核記錄

若要查看該應用程式的所有同意授與,請依同意授與應用程式篩選活動

  • 使用 Microsoft Entra 系統管理中心稽核日誌

  • 使用 Microsoft Graph 查詢稽核記錄

    a) 篩選特定時間範圍:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b)篩選稽核日志,以取得「同意應用程式」稽核記錄條目:

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) 使用 Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

如需詳細資訊,請參閱 應用程式同意授權調查劇本

使用者可以授權應用程式存取受保護資源上的某些資料,同時擔任該使用者。 允許此類型存取的許可權稱為「委派許可權」或 使用者同意

若要尋找使用者同意的應用程式,請使用 LogAnalytics 來搜尋稽核記錄:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

檢查稽核記錄,以確定所授予的許可權是否過於廣泛(租戶範圍或經由管理員同意)

檢閱授與給應用程式或服務主體的許可權可能是一項耗時的工作。 從瞭解 Microsoft Entra ID 中的潛在 風險權限 開始。

現在,請遵循在應用程式同意授與調查中列舉和檢閱許可權的指引。

檢查是否有不應具備此能力的使用者身分識別授予了許可權,或是否在異常的日期和時間執行了這些操作。

使用審計日誌檢視:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

您也可以使用 Microsoft Entra 稽核記錄,依 同意應用程式進行篩選。 在「稽核日誌詳細資料」區段中,按一下 修改的屬性,然後檢閱 ConsentAction.Permissions

如何使用 Microsoft Entra 稽核記錄的螢幕快照。

遏制步驟

將一或多個應用程式或工作負載身分識別識別識別為惡意或遭入侵之後,您可能不想立即復原此應用程式的認證,也不想立即刪除應用程式。

重要

執行下列步驟之前,您的組織必須權衡停用應用程式的安全性影響和業務影響。 如果停用應用程式的商務影響太大,請考慮準備並移至此程序的復原階段。

停用遭入侵的應用程式

典型的遏制策略牽涉到停用已識別應用程式的登入功能,為事件應變小組或受影響的業務單位爭取時間,以評估刪除或密鑰更換帶來的影響。 如果您的調查導致您認為系統管理員帳戶認證也遭到入侵,此類型的活動應該與收回事件協調,以確保存取租使用者的所有路由都會同時關閉。

如何停用使用者登入的螢幕快照。

您也可以使用下列 Microsoft Graph PowerShell 程式代碼來停用應用程式的登入:

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

復原步驟

補救服務主體

  1. 列出指派給 Risky Service Principal 的所有認證。 若要這樣做,最好的方法是使用 GET ~/application/{id} 執行Microsoft Graph 呼叫,其中傳遞的標識碼是應用程式對象標識碼。

    • 解析憑證的輸出。 輸出可能包含密碼憑證(passwordCredentials)或金鑰憑證(keyCredentials)。 記錄所有金鑰標識碼。

      "keyCredentials": [],
           "parentalControlSettings": {
               "countriesBlockedForMinors": [],
               "legalAgeGroupRule": "Allow"
           },
           "passwordCredentials": [
               {
                   "customKeyIdentifier": null,
                   "displayName": "Test",
                   "endDateTime": "2021-12-16T19:19:36.997Z",
                   "hint": "7~-",
                   "keyId": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
                   "secretText": null,
                   "startDateTime": "2021-06-16T18:19:36.997Z"
               }
           ],
      
  2. 使用應用程式的 addKey API 將新的 (x509) 憑證憑據新增至應用程式物件。

    POST ~/applications/{id}/addKey
    
  3. 立即移除所有舊的認證。 針對每個舊的密碼憑證,請使用指定的方法將其移除:

    POST ~/applications/{id}/removePassword
    

    對於每個舊的金鑰認證,請使用指定方法將其移除:

    POST ~/applications/{id}/removeKey
    
  4. 修正與應用相關聯的所有服務主體。 如果您的租用戶裝載/註冊多租使用者應用程式,以及/或註冊與應用程式相關聯的多個服務主體,請遵循此步驟。 執行與先前所列項目類似的步驟:

  • GET ~/servicePrincipals/{id}

  • 在回應中尋找 passwordCredentials 和 keyCredentials,記錄所有舊的金鑰 ID

  • 拿掉所有舊的密碼和金鑰認證。 使用:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.
    

補救受影響的服務主體資源

依照以下優先順序,透過輪替來修正服務主體憑證可存取的 KeyVault 秘密:

  • 使用 GetSecret 調用時,秘密會被直接公開。
  • 公開 KeyVaults 中的其餘秘密。
  • 公開訂閱的其餘秘密。

如需詳細資訊,請參閱 以互動方式移除和變換服務主體或應用程式的憑證和秘密。

如需應用程式的Microsoft Entra SecOps 指引,請參閱 application Microsoft Entra 安全性作業指南

依優先順序排序,此案例會是:

  • 更新 Graph PowerShell Cmdlet (新增/移除 ApplicationKey + ApplicationPassword) 檔,以包含認證變換的範例。
  • 將自定義 Cmdlet 新增至 Microsoft Graph PowerShell,以簡化此案例的處理。

停用或刪除惡意應用程式

應用程式可以停用或刪除。 若要停用應用程式,請在 [啟用讓使用者登入] 下,將切換開關移至 [否]。

您可以在 Azure 入口網站 或透過 Microsoft Graph API 暫時或永久刪除應用程式。 當您進行軟刪除時,應用程式可以在刪除後的 30 天內復原。

DELETE /applications/{id}

若要永久刪除應用程式,請使用此Microsoft Graph API 呼叫:

DELETE /directory/deletedItems/{id}

如果您停用或虛刪除應用程式,請在 Microsoft Entra 稽核記錄中設定監視,以偵測狀態是否變更為已啟用或復原。

針對已啟用的功能進行記錄:

  • 服務 - 核心目錄
  • 活動類型 - 更新服務主體
  • 類別 - 應用程式管理
  • 由(執行者)起始 - 執行者的 UPN
  • 目標 -應用程式識別碼和顯示名稱
  • 已修改的屬性 - 屬性名稱 = 帳戶已啟用,新值 = true

復原過程的日誌:

  • 服務 - 核心目錄
  • 活動類型 - 新增服務主體
  • 類別 - 應用程式管理
  • 由(演員)起始 - 演員的 UPN
  • 目標 -應用程式識別碼和顯示名稱
  • 已修改的屬性 - 屬性名稱 = 帳戶已啟用,新值 = true

注意

Microsoft全域停用發現違反其服務條款的應用程式。 在這些情況下,這些應用程式會在 Microsoft Graph 中相關的應用程式服務主體資源類型的disabledByMicrosoftStatus屬性上顯示DisabledDueToViolationOfServicesAgreement。 為防止這些物件未來在組織中再次具現化,您無法刪除這些物件。

針對工作負載身分識別實施身分保護

Microsoft偵測到工作負載身分在登入行為和離線入侵指標上的風險。

如需詳細資訊,請參閱 使用 Identity Protection 保護工作負載身分識別。

這些警示會出現在 Identity Protection 入口網站中,並可透過 診斷設定Identity Protection API 導出至 SIEM 工具。

如何在 Identity Protection 入口網站中檢閱風險和警示的螢幕快照。

針對風險工作負載身分識別的條件式存取

條件式存取可讓您封鎖您指定 Identity Protection 何時將其標示為「有風險」的特定帳戶的存取。 透過條件式存取強制執行目前僅限於單一租用戶應用程式。

如何根據條件式存取原則控制使用者存取的螢幕快照。

如需詳細資訊,請參閱 用於工作負載身分識別的條件式存取

實作應用程式風險原則

檢閱 [Microsoft Entra ID] > [企業應用程式] > [同意和權限] > [使用者同意設定] 的設定。

如何允許使用者同意應用程式的螢幕快照。

若要檢閱設定選項,請參閱 設定使用者同意應用程式的方式。

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

大部分的組織都會停用其使用者同意應用程式的能力。 若要讓使用者仍要求同意應用程式並具備系統管理檢閱功能,建議您實作系統管理員同意工作流程。 請遵循系統管理員 同意工作流程步驟 ,在您的租使用者中加以設定。

針對高特殊許可權作業,例如系統管理員同意,請在我們的 指引中定義特殊許可權存取策略。

以風險為基礎的逐步同意有助於減少使用者對惡意應用程式的風險。 例如,針對未經發行者驗證且需要非基本權限的新註冊多租用戶應用程式,其同意要求會被視為具有風險。 如果系統偵測到風險性使用者同意要求,其要求會需要「升級」至系統管理員同意。 這項升級功能預設為啟用,但只有在啟用使用者同意時,才會產生行為變更。

請確定已在您的租用戶中啟用,並檢閱此處所述的組態設定。

參考資料

其他事件應變手冊

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

事件回應資源