Sdílet prostřednictvím

Vyšetřování ohrožených a škodlivých aplikací

  • Článek

Tento článek obsahuje pokyny k identifikaci a vyšetřování škodlivých útoků na jednu nebo více aplikací v tenantovi zákazníka. Podrobné pokyny vám pomůžou provést požadovanou nápravnou akci k ochraně informací a minimalizaci dalších rizik.

  • Požadavky: Řeší konkrétní požadavky, které je potřeba dokončit před zahájením šetření. Protokolování, které by mělo být zapnuté, role a oprávnění se vyžadují mimo jiné.
  • Pracovní postup: Zobrazuje logický tok, podle kterého byste měli provést toto šetření.
  • Kroky šetření: Obsahuje podrobné pokyny pro toto konkrétní šetření.
  • Kroky zahrnutí: Obsahuje kroky k zakázání ohrožených aplikací.
  • Kroky obnovení: Obsahuje základní kroky týkající se obnovení nebo zmírnění škodlivého útoku na ohrožené aplikace.
  • Odkazy: Obsahuje další materiály pro čtení a odkazy.

Požadavky

Před zahájením šetření se ujistěte, že máte správné nástroje a oprávnění ke shromažďování podrobných informací.

Požadované nástroje

V případě efektivního šetření nainstalujte na svůj počítač pro šetření následující modul PowerShellu a sadu nástrojů:

Workflow

Podrobný postup šetření

Postup prověřování

Pro účely tohoto šetření předpokládejme, že máte buď indikaci potenciálního ohrožení zabezpečení aplikace ve formě sestavy uživatele, příkladu protokolů přihlášení Microsoft Entra nebo detekce ochrany identit. Nezapomeňte dokončit a povolit všechny požadované požadované kroky.

Tento playbook se vytvoří se záměrem, že ne všichni zákazníci Microsoftu a jejich týmy pro šetření mají k dispozici nebo nakonfigurovanou úplnou sadu licencí Microsoft 365 E5 nebo Microsoft Entra ID P2. Tento playbook v případě potřeby zvýrazní další možnosti automatizace.

Určení typu aplikace

V rané fázi šetření je důležité určit typ aplikace (více nebo jednoho tenanta), abyste získali správné informace potřebné k tomu, aby se spojte s vlastníkem aplikace. Další informace naleznete v tématu Tenantancy v Microsoft Entra ID.

Víceklientských aplikací

U víceklientských aplikací je aplikace hostovaná a spravovaná třetí stranou. Identifikujte proces potřebný k tomu, aby se spojte a nahlásili problémy vlastníkovi aplikace.

Aplikace s jedním tenantem

Vyhledejte kontaktní údaje vlastníka aplikace ve vaší organizaci. Najdete ho na kartě Vlastníci v části Podnikové aplikace . Případně může mít vaše organizace databázi, která tyto informace obsahuje.

Můžete také spustit tento dotaz Microsoft Graphu:

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

Kontrola identity Identity Protection – rizikové identity úloh

Tato funkce je ve verzi Preview v době psaní tohoto playbooku a licenčních požadavků na jeho použití. Rizikové identity úloh můžou být triggerem pro zkoumání instančního objektu, ale dají se také použít k dalšímu prozkoumání dalších triggerů, které jste identifikovali. Stav rizika instančního objektu můžete zkontrolovat pomocí karty Identity Protection – rizikové identity úloh nebo můžete použít rozhraní Microsoft Graph API.

Portál pro detekci rizik

Podrobnosti o detekci rizik

Ukázka rozhraní Graph API pro detekci rizik instančního objektu

Kontrola neobvyklého chování přihlašování

Prvním krokem šetření je vyhledání důkazů o neobvyklých vzorech ověřování při použití instančního objektu. Na webu Azure Portal, Azure Monitoru, Microsoft Sentinelu nebo ve zvoleném systému správy událostí (SIEM) vaší organizace vyhledejte v části Přihlášení instančního objektu následující informace:

  • Umístění – je instanční objekt ověřování z umístění\IP adres, které byste neočekávejte?
  • Selhání – u instančního objektu existuje velký počet selhání ověřování?
  • Časová razítka – dochází k úspěšným ověřováním v době, kdy byste neočekávali?
  • Frekvence – existuje zvýšená frekvence ověřování pro instanční objekt?
  • Nevracení přihlašovacích údajů – jsou nějaké přihlašovací údaje aplikace pevně zakódované a publikované ve veřejném zdroji, jako je GitHub?

Pokud jste nasadili službu Entra ID Identity Protection – rizikové identity úloh, zkontrolujte detekce podezřelých přihlášení a úniku přihlašovacích údajů. Další informace najdete v tématu zajištění rizik identit úloh.

Kontrola cílového prostředku

V rámci přihlášení instančního objektu zkontrolujte také prostředek , ke kterému instanční objekt přistupoval během ověřování. Je důležité získat vstup od vlastníka aplikace, protože jsou obeznámeni s prostředky, ke kterým má instanční objekt přistupovat.

Kontrola prostředku pro instanční objekt

Kontrola neobvyklých změn přihlašovacích údajů

Protokoly auditu slouží k získání informací o změnách přihlašovacích údajů v aplikacích a instančních objektech. Filtrovat podle kategorie podle správy aplikací a aktivity podle aktualizace aplikace – Certifikáty a správa tajných kódů.

  • Zkontrolujte, jestli jsou nově vytvořené nebo neočekávané přihlašovací údaje přiřazené instančnímu objektu.
  • Zkontrolujte přihlašovací údaje instančního objektu pomocí rozhraní Microsoft Graph API.
  • Zkontrolujte aplikace i přidružené objekty instančního objektu.
  • Zkontrolujte libovolnou vlastní roli , kterou jste vytvořili nebo upravili. Poznamenejte si níže uvedená oprávnění:

Kontrola vytvořených nebo upravených vlastních rolí

Pokud jste nasadili zásady správného řízení aplikací v programu Microsoft Defender for Cloud Apps, podívejte se na web Azure Portal, kde najdete upozornění týkající se aplikace. Další informace najdete v tématu Začínáme s detekcí a nápravou hrozeb aplikací.

Pokud jste nasadili službu Identity Protection, zkontrolujte sestavu Detekce rizik a v identitě uživatele nebo úlohy "historie rizik".

Portál pro detekci rizik

Pokud jste nasadili Microsoft Defender for Cloud Apps, ujistěte se, že je povolená zásada Neobvyklé přidání přihlašovacích údajů do aplikace OAuth a zkontrolujte otevřená upozornění.

Další informace najdete v tématu Neobvyklé přidání přihlašovacích údajů do aplikace OAuth.

Kromě toho můžete zadávat dotazy na rozhraní API servicePrincipalRiskDetections a user riskDetections a načíst tyto detekce rizik.

Vyhledání neobvyklých změn konfigurace aplikace

  • Zkontrolujte oprávnění rozhraní API přiřazená aplikaci a ujistěte se, že jsou oprávnění konzistentní s očekávaným způsobem aplikace.
  • Zkontrolujte protokoly auditu (filtrování aktivity podle aktualizace aplikace nebo aktualizace instančního objektu).
  • Ověřte, jestli jsou připojovací řetězec konzistentní a jestli byla změněna adresa URL odhlášení.
  • Ověřte, jestli jsou domény v adrese URL v souladu s doménami registrovanými.
  • Určete, jestli někdo přidal neautorizovanou adresu URL přesměrování.
  • Ověřte vlastnictví identifikátoru URI přesměrování, který vlastníte, a ujistěte se, že nevypršela platnost a byla požadována nežádoucím uživatelem.

Pokud jste nasadili Microsoft Defender for Cloud Apps, zkontrolujte na webu Azure Portal upozornění týkající se aktuálně prošetřující aplikace. Pro aplikace OAuth nejsou ve výchozím nastavení povolené všechny zásady upozornění, proto se ujistěte, že jsou všechny tyto zásady povolené. Další informace najdete v zásadách aplikací OAuth. Můžete si také zobrazit informace o prevalenci aplikací a nedávné aktivitě na kartě Šetření>OAuth Apps.

Kontrola podezřelých aplikačních rolí

  • Můžete také použít protokoly auditu. Filtrovat aktivitu přidáním přiřazení role aplikace k instančnímu objektu
  • Ověřte, jestli mají přiřazené role vysoké oprávnění.
  • Ověřte, jestli jsou tato oprávnění nezbytná.

Kontrola neověřených komerčních aplikací

  • Zkontrolujte, jestli se používají komerční galerie (publikované a ověřené verze).

Kontrola informací o zpřístupnění informací o vlastnosti keyCredential

Zkontrolujte potenciální zpřístupnění informací o vlastnosti keyCredential, jak je uvedeno v CVE-2021-42306.

Pokud chcete identifikovat a opravit ovlivněné aplikace Microsoft Entra přidružené k ovlivněným účtům Automation Spustit jako, přejděte k pokynům k nápravě v úložišti GitHubu.

Důležité

Důkaz o ohrožení zabezpečení: Pokud zjistíte důkaz o ohrožení zabezpečení, je důležité provést kroky zvýrazněné v oddílech omezení a obnovení. Tyto kroky pomáhají vyřešit riziko, ale proveďte další šetření, abyste pochopili zdroj ohrožení zabezpečení, abyste se vyhnuli dalšímu dopadu a zajistili, že budou odstraněni chybní aktéři.

Existují dvě primární metody získání přístupu k systémům prostřednictvím použití aplikací. První zahrnuje souhlas aplikace správcem nebo uživatelem, obvykle prostřednictvím útoku phishing. Tato metoda je součástí počátečního přístupu k systému a často se označuje jako "phishing souhlasu".

Druhá metoda zahrnuje již ohrožený účet správce, který vytváří novou aplikaci pro účely trvalosti, shromažďování dat a udržení pod radarem. Například napadený správce by mohl vytvořit aplikaci OAuth se zdánlivě neškodným názvem, vyhnout se detekci a povolit dlouhodobý přístup k datům bez nutnosti účtu. Tato metoda se často projevuje ve státních útocích států.

Tady je několik kroků, které je možné provést k dalšímu prozkoumání.

Zkontrolujte, jestli microsoft 365 Unified Audit Log (UAL) nehlásí útoky phishing za posledních 7 dnů.

Někdy platí, že když útočníci používají škodlivé nebo ohrožené aplikace jako prostředek trvalosti nebo exfiltrace dat, je zapojena phishingová kampaň. Na základězjištěních

  • Vlastníci aplikace
  • Správa souhlasu

Projděte si identity pro označení útoků phishing za posledních 24 hodin. Pokud není k dispozici žádná okamžitá indikace, zvyšte toto časové období na 7, 14 a 30 dní. Podrobný playbook pro vyšetřování útoků phishing najdete v playbooku pro šetření útoku phishing.

Vyhledání souhlasů se škodlivými aplikacemi za posledních 7 dnů

Pokud chcete získat aplikaci přidanou do tenanta, útočníci zneužní uživatele nebo správce, aby souhlasili s aplikacemi. Další informace o známkách útoku najdete v playbooku Prošetření udělení souhlasu aplikace.

Kontrola protokolů auditu

Pokud chcete zobrazit všechny udělení souhlasu pro danou aplikaci, vyfiltrujte aktivitu podle souhlasu s aplikací.

  • Použití protokolů auditu Centra pro správu Microsoft Entra

  • Použití Microsoft Graphu k dotazování protokolů auditu

    a) Filtrujte pro určitý časový rámec:

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

b) Vyfiltrujte protokoly auditu pro položky protokolu auditu "Souhlas s aplikacemi":

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": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "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) Použití Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Další informace najdete v playbooku o udělení souhlasu aplikace.

Uživatel může autorizovat aplikaci pro přístup k některým datům v chráněném prostředku a současně jednat jako tento uživatel. Oprávnění, která umožňují tento typ přístupu, se nazývají "delegovaná oprávnění" nebo souhlas uživatele.

Pokud chcete vyhledat aplikace, které uživatelé odsouhlasili, pomocí LogAnalytics prohledejte protokoly auditu:

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

Zkontrolujte protokoly auditu a zjistěte, jestli jsou udělená oprávnění příliš široká (s souhlasem celého tenanta nebo správcem).

Kontrola oprávnění udělených aplikaci nebo instančnímu objektu může být časově náročná úloha. Začněte pochopením potenciálně rizikových oprávnění v Microsoft Entra ID.

Teď postupujte podle pokynů k vytvoření výčtu a kontrole oprávnění v šetření udělení souhlasu aplikace.

Zkontrolujte, jestli byla oprávnění udělena identitami uživatelů, které by k tomu neměly mít možnost, nebo jestli se akce prováděly v podivných datech a časech.

Projděte si protokoly auditu:

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

Můžete také použít protokoly auditu Microsoft Entra, filtrovat podle souhlasu s aplikací. V části Podrobnosti protokolu auditu klepněte na tlačítko Změněné vlastnosti a pak zkontrolujte ConsentAction.Permissions:

Použití protokolů auditu Microsoft Entra

Kroky pro zahrnutí

Po identifikacijednéch

Důležité

Než provedete následující krok, musí vaše organizace zvážit dopad zabezpečení a obchodní dopad zakázání aplikace. Pokud je obchodní dopad zakázání aplikace příliš velký, zvažte přípravu a přechod do fáze obnovení tohoto procesu.

Zakázání ohrožené aplikace

Typická strategie blokování zahrnuje zakázání přihlášení k identifikované aplikaci, aby týmu reakce na incidenty nebo ovlivněné obchodní jednotce poskytl čas vyhodnotit dopad odstranění nebo postupného uvedení klíče. Pokud vás šetření povede k přesvědčení, že dojde také k ohrožení přihlašovacích údajů účtu správce, měl by být tento typ aktivity koordinovaný s událostí vyřazení, aby se zajistilo, že všechny trasy pro přístup k tenantovi budou současně oříznuté.

Přepnutím zakažte uživatele, aby se přihlásili.

K zakázání přihlášení k aplikaci můžete použít také následující kód Microsoft Graph PowerShellu :

# 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
   
}

Kroky obnovení

Náprava instančních objektů

  1. Zobrazí seznam všech přihlašovacích údajů přiřazených k rizikovému instančnímu objektu. Nejlepším způsobem, jak to udělat, je provést volání Microsoft Graphu pomocí metody GET ~/application/{id}, kde id předané je ID objektu aplikace.

    • Parsujte výstup pro přihlašovací údaje. Výstup může obsahovat hodnoty passwordCredentials nebo keyCredentials. Zaznamenejte id klíčů pro všechny.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Přidejte do objektu aplikace nové přihlašovací údaje certifikátu (x509) pomocí rozhraní API addKey aplikace.

    POST ~/applications/{id}/addKey

  3. Okamžitě odeberte všechny staré přihlašovací údaje. Pro každé staré přihlašovací údaje hesla ho odeberte pomocí:

    POST ~/applications/{id}/removePassword

    Pro každé staré přihlašovací údaje klíče ho odeberte pomocí:

    POST ~/applications/{id}/removeKey

  4. Opravte všechny instanční objekty přidružené k aplikaci. Postupujte podle tohoto kroku, pokud váš tenant hostuje nebo zaregistruje aplikaci s více tenanty a/nebo zaregistruje více instančních objektů přidružených k aplikaci. Proveďte podobné kroky jako v předchozím seznamu:

  • GET ~/servicePrincipals/{id}

  • Vyhledání passwordCredentials a keyCredentials v odpovědi, zaznamenání všech starých ID klíčů

  • Odeberte všechna stará hesla a přihlašovací údaje ke klíči. Použijte:

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

Náprava ovlivněných prostředků instančního objektu

Opravte tajné kódy služby KeyVault, ke kterým má instanční objekt přístup, tím, že je otočíte v následující prioritě:

  • Tajné kódy přímo vystavené pomocí volání GetSecret .
  • Zbývající tajné kódy v vystavených službě KeyVaults.
  • Zbývající tajné kódy pro vystavená předplatná.

Další informace najdete v tématu Interaktivní odebrání a vrácení certifikátů a tajných kódů instančního objektu nebo aplikace.

Pokyny pro Microsoft Entra SecOps k aplikacím najdete v průvodci operacemi zabezpečení Microsoft Entra pro aplikace.

V pořadí podle priority by tento scénář byl:

  • Aktualizujte dokumentaci k rutinám PowerShellu pro Graph (Přidání nebo odebrání ApplicationKey + ApplicationPassword), abyste zahrnuli příklady pro vrácení přihlašovacích údajů.
  • Přidání vlastních rutin do Prostředí Microsoft Graph PowerShell, které tento scénář zjednodušuje.

Zakázání nebo odstranění škodlivých aplikací

Aplikaci je možné zakázat nebo odstranit. Pokud chcete aplikaci zakázat, přesuňte v části Povoleno, aby se uživatelé přihlásili, přepínač na Ne.

Aplikaci můžete odstranit buď dočasně, nebo trvale, na webu Azure Portal nebo prostřednictvím rozhraní Microsoft Graph API. Při obnovitelném odstranění je možné aplikaci obnovit až 30 dnů po odstranění.

DELETE /applications/{id}

Pokud chcete aplikaci trvale odstranit, použijte toto volání rozhraní Microsoft Graph API:

DELETE /directory/deletedItems/{id}

Pokud aplikaci zakážete nebo pokud aplikaci obnovitelné odstranění zakážete, nastavte monitorování v protokolech auditu Microsoft Entra, abyste se dozvěděli, jestli se stav změní zpět na povolenou nebo obnovenou.

Protokolování pro povolené:

  • Služba – základní adresář
  • Typ aktivity – aktualizace instančního objektu
  • Kategorie – Správa aplikací
  • Inicializován (actor) - HLAVNÍHO názvu uživatele (UPN) objektu actor
  • Cíle – ID aplikace a zobrazovaný název
  • Změněné vlastnosti – Název vlastnosti = účet povolen, nová hodnota = true

Protokolování pro obnovení:

  • Služba – základní adresář
  • Typ aktivity – Přidání instančního objektu
  • Kategorie – Správa aplikací
  • Inicializován (actor) - HLAVNÍHO názvu uživatele (UPN) objektu actor
  • Cíle – ID aplikace a zobrazovaný název
  • Změněné vlastnosti – Název vlastnosti = účet povolen, nová hodnota = true

Poznámka: Microsoft globálně zakáže aplikace, které se nacházejí v porušení podmínek služby. V těchto případech se tyto aplikace zobrazují DisabledDueToViolationOfServicesAgreement ve disabledByMicrosoftStatus vlastnosti souvisejících typů prostředků aplikace a instančního objektu v Microsoft Graphu. Pokud chcete zabránit jejich vytvoření instance ve vaší organizaci v budoucnu, nemůžete tyto objekty odstranit.

Implementace identity Identity Protection pro identity úloh

Microsoft detekuje riziko u identit úloh napříč chováním přihlašování a offline indikátory ohrožení zabezpečení.

Další informace najdete v tématu Zabezpečení identit úloh pomocí identity Identity Protection.

Tyto výstrahy se zobrazují na portálu Identity Protection a dají se exportovat do nástrojů SIEM prostřednictvím diagnostických Nastavení nebo rozhraní API služby Identity Protection.

Kontrola rizik a upozornění na portálu Identity Protection

Podmíněný přístup pro rizikové identity úloh

Podmíněný přístup umožňuje blokovat přístup pro konkrétní účty, které určíte, když je služba Identity Protection označí jako ohrožené. Všimněte si, že vynucení prostřednictvím podmíněného přístupu je aktuálně omezeno pouze na aplikace s jedním tenantem.

Řízení přístupu uživatelů na základě zásad podmíněného přístupu

Další informace najdete v tématu Podmíněný přístup pro identity úloh.

Implementace zásad rizik aplikací

Zkontrolujte nastavení souhlasu uživatele v části Podnikové aplikace>Microsoft Entra ID>Souhlas a oprávnění>Souhlas uživatele.

V možnostech vyberte Povolit souhlas uživatele pro aplikace.

Pokud chcete zkontrolovat možnosti konfigurace, přečtěte si, jak uživatelé souhlasí s aplikacemi.

Když vývojář aplikace nasměruje uživatele na koncový bod souhlasu správce se záměrem udělit souhlas pro celého tenanta, označuje se jako tok souhlasu správce. Aby tok souhlasu správce fungoval správně, musí vývojáři aplikací v manifestu aplikace vypsat všechna oprávnění ve vlastnosti RequiredResourceAccess.

Většina organizací zakáže uživatelům souhlas s aplikacemi. Pokud chcete uživatelům umožnit, aby stále požadovali souhlas s aplikacemi a měli možnost kontroly správy, doporučujeme implementovat pracovní postup souhlasu správce. Postupujte podle kroků pracovního postupu souhlasu správce a nakonfigurujte ho ve vašem tenantovi.

Pro vysoce privilegované operace, jako je souhlas správce, je definována strategie privilegovaného přístupu definovaná v našich doprovodných materiálech.

Souhlas založený na rizikových krocích pomáhá snížit riziko ohrožení uživatelů škodlivých aplikací. Například žádosti o souhlas pro nově zaregistrované víceklientských aplikací, které nejsou ověřené vydavatelem, a vyžadují jiná než základní oprávnění, se považují za riziková. Pokud se zjistí riziková žádost o souhlas uživatele, vyžaduje žádost místo toho "krok nahoru" k souhlasu správce. Tato funkce pro zvýšení kapacity je ve výchozím nastavení povolená, ale výsledkem je změna chování pouze v případě, že je povolený souhlas uživatele.

Ujistěte se, že je ve vašem tenantovi povolená, a zkontrolujte zde uvedená nastavení konfigurace.

Reference

Další playbooky reakce na incidenty

Projděte si pokyny k identifikaci a prošetřování těchto dalších typů útoků:

Zdroje informací o reakcích na incidenty