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

Tento článek obsahuje pokyny k identifikaci a zkoumá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: Před zahájením šetření se zabývá konkrétními požadavky, které je potřeba dokončit. Například protokolování, které by mělo být zapnuté, role a oprávnění vyžadované mimo jiné.
  • Pracovního postupu: Zobrazuje logický tok, podle kterého byste měli provést toto šetření.
  • Kroky šetření: Obsahuje podrobné pokyny k tomuto konkrétnímu šetření.
  • Kroky omezení: Obsahuje postup 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 referenční materiály.

Požadavky

Než začnete vyšetřování, ujistěte se, že máte správné nástroje a oprávnění ke shromažďování podrobných informací o aplikacích, které máte podezření, že útok na škodlivý útok zneškodní.

Požadované nástroje

Pro efektivní šetření nainstalujte následující modul PowerShellu a sadu nástrojů na váš počítač pro šetření:

Pracovní postup

Detailed flow of the investigation steps

Postup prověřování

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

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

Určení typu aplikace

Je důležité určit typ aplikace (více nebo jednoho tenanta) v rané fázi šetření, abyste získali správné informace potřebné k tomu, aby se mohli obrátit na vlastníka aplikace. Další informace najdete v tématu Tenantancy v Azure Active Directory.

Víceklientské aplikace

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

Jednoklientové aplikace

Najděte 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 Protection – identity rizikových úloh

Tato funkce je ve verzi Preview v době psaní tohoto playbooku a licenčních požadavků na jeho použití. Identity rizikových úloh můžou být triggerem pro zkoumání instančního objektu, ale dají se také použít k dalšímu zkoumání dalších triggerů, které jste možná 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.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Kontrola neobvyklého chování při 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, Azure Sentinelu nebo ve zvoleném systému SIEM (Security Information and Event Management) vaší organizace vyhledejte v části Přihlášení instančního objektu následující:

  • Umístění – je instanční objekt ověřovací z umístění\IP adres, které byste neočekával?
  • Selhání – existuje u instančního objektu velký počet selhání ověřování?
  • Časové razítko – dochází k úspěšným ověřováním, ke kterým dochází v době, kdy byste neočekával?
  • Frekvence – existuje zvýšená frekvence ověřování instančního objektu?
  • Únik 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 Identity Protection – rizikové identity úloh, zkontrolujte detekce podezřelých přihlašovacích údajů a úniku přihlašovacích údajů. Další informace najdete v tématu o zadržová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řistupuje během ověřování. Je důležité mít vstup od vlastníka aplikace, protože budou obeznámeni s prostředky, ke kterým má instanční objekt přistupovat.

Check the Resource for Service Principal

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. Filtr pro kategorii 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.
  • Pomocí rozhraní Microsoft Graph API zkontrolujte přihlašovací údaje instančního objektu.
  • Zkontrolujte aplikace i přidružené objekty instančního objektu.
  • Zkontrolujte libovolnou vlastní roli , kterou jste možná vytvořili nebo upravili. Všimněte si níže uvedených oprávnění:

Check custom roles that may be created or modified

Pokud jste doplněk zásad správného řízení aplikace nasadili, zkontrolujte na webu Azure Portal upozornění týkající se aplikace. Další informace najdete v tématu Začínáme s detekcí hrozeb a nápravou aplikací.

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

Risk Detection portal

Pokud jste nasadili Microsoft Defender for Cloud Apps, ujistěte se, že je povolená zásada neobvyklého přidání přihlašovacích údajů k aplikaci 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 rozhraní API riskDetections pro načtení těchto detekcí rizik.

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

  • Zkontrolujte oprávnění rozhraní API přiřazená aplikaci, abyste měli jistotu, že oprávnění jsou konzistentní s očekávaným očekáváním aplikace.
  • Zkontrolujte protokoly auditu (aktivitu filtrování podle aktualizace aplikace nebo instančního objektu aktualizace).
  • Ověřte, jestli jsou připojovací řetězce konzistentní a jestli se změnila adresa URL odhlášení.
  • Ověřte, jestli jsou domény v adrese URL v souladu s registrovanými doménami.
  • Určete, jestli někdo přidal neautorizovanou adresu URL přesměrování.
  • Potvrďte vlastnictví identifikátoru URI přesměrování, které vlastníte, abyste zajistili, ž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 aplikace, kterou právě prošetřujete. Pro aplikace OAuth nejsou ve výchozím nastavení povolené všechny zásady upozornění, proto se ujistěte, že jsou všechny povolené. Další informace najdete v zásadách aplikací OAuth. Informace o předvalanci aplikací a nedávné aktivitě můžete zobrazit také na kartě Šetření>aplikací OAuth .

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

  • Můžete to také prozkoumat pomocí protokolů 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 označení zpřístupnění informací o vlastnosti keyCredential

Zkontrolujte svého tenanta, že informace o potenciálním zpřístupnění informací o vlastnosti keyCredential jsou popsané v CVE-2021-42306.

Pokud chcete identifikovat a napravit ovlivněné aplikace Azure AD přidružené k ovlivněným účtům Automation Run-As, přejděte k pokynům k nápravě na githubovém úložišti.

Důležité

Důkazy o ohrožení zabezpečení: Pokud zjistíte důkazy o ohrožení zabezpečení, je důležité provést kroky zvýrazněné v částech o zahrnutí a obnovení. To pomůže vyřešit riziko, ale bude potřeba další šetření, abyste pochopili zdroj kompromisu, abyste se vyhnuli dalšímu dopadu a zajistili, že budou odstraněni špatní 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. To by bylo 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 zůstat pod radarem. Například aplikaci OAuth může vytvořit ohrožený správce se zdánlivě neschválným názvem, vyhnout se detekci a povolit dlouhodobý přístup k datům bez nutnosti účtu. To se často projevuje v národních státních útocích.

Níže jsou uvedené některé kroky, které je možné provést k dalšímu šetření.

Zkontrolujte, jestli protokol UAL (Unified Audit Log) M365 (Unified Audit Log) za posledních 7 dnů indikuje phishing.

Někdy platí, že když útočníci používají škodlivé nebo ohrožené aplikace jako prostředek trvalosti nebo exfiltrace dat, je zapojena kampaň phishing. Na základě zjištění z předchozích kroků byste měli zkontrolovat identity těchto:

  • Vlastníci aplikací
  • Správci souhlasu

Zkontrolujte identity pro označení útoků phishing za posledních 24 hodin. Tento časový rozsah v případě potřeby zvyšte na 7, 14 a 30 dní, pokud neexistují okamžité indikace. Podrobný playbook pro vyšetřování útoků phishing najdete v playbooku phishing pro šetření.

Hledání souhlasů se zlými úmysly aplikace za posledních 7 dnů

Pokud chcete získat aplikaci přidanou do tenanta, útočníci zpochybní 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 na portálu Azure AD

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

    a) Filtr 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 Prošetření 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 najít aplikace, které uživatelé odsouhlasili, použijte LogAnalytics k prohledávání protokolů 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á (pro celého tenanta nebo souhlas správce).

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 porozumět potenciálně rizikovým oprávněním v Azure AD.

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

Zkontrolujte, jestli byla oprávnění udělena identitami uživatelů, kteří by to neměli dělat, nebo jestli se akce prováděly v podivných datech a časech.

Kontrola pomocí protokolů 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 Azure AD, filtrovat podle souhlasu s aplikací. V části Podrobnosti protokolu auditu klepněte na tlačítko Změněné vlastnosti a pak zkontrolujte ConsentAction.Permissions:

Use the Azure AD Audit Logs

Kroky zachycování

Jakmile identifikujete jednu nebo více aplikací nebo identit úloh jako škodlivé nebo ohrožené, možná nebudete chtít přihlašovací údaje pro tuto aplikaci okamžitě vrátit, ani aplikaci okamžitě odstranit. Důrazně doporučujeme postupovat podle osvědčených postupů pro reakci na incidenty.

Důležité

Než provedete následující krok, musí vaše organizace zvážit dopad na 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 zahrnutí zahrnuje zakázání přihlášení k identifikované aplikaci, aby tým reakce na incidenty nebo ovlivněný obchodní jednotku vyhodnotili dopad postupného odstranění nebo klíče. Pokud šetření vede k přesvědčení, že došlo 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é.

Toggle to disable users to sign-in

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

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

# Check if a service principal already exists for the app
$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
   # Service principal exists already, disable it
   Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   $servicePrincipal = New-AzureADServicePrincipal -AppId $appId -AccountEnabled $false
}

Kroky obnovení

Náprava instančních objektů

  1. Vypíše všechny přihlašovací údaje přiřazené k rizikovému instančnímu objektu. Nejlepším způsobem, jak to provést, je provést volání Microsoft Graphu pomocí metody GET ~/application/{id}, kde id bylo předáno jako ID objektu aplikace.

    • Parsujte výstup pro přihlašovací údaje. Výstup může obsahovat passwordCredentials nebo keyCredentials. Poznamenejte si 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ý klíč přihlašovací údaje ho odeberte pomocí:

    POST ~/applications/{id}/removeKey
    
  4. Opravte všechny instanční objekty přidružené k aplikaci. Postupujte podle toho, 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ýše uvedené:

  • GET ~/servicePrincipals/{id}

  • V odpovědi vyhledejte passwordCredentials a keyCredentials, zaznamenejte všechny staré ID klíčů.

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

    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 obměnuje, v následující prioritě:

  • Tajné kódy jsou přímo vystavené pomocí volání GetSecret .
  • Zbývající tajné kódy v vystavených keyVaults.
  • Zbývající tajné kódy v rámci vystavených předplatných.

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 k azure AD SecOps pro aplikace najdete v průvodci operacemi zabezpečení Azure Active Directory pro aplikace.

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

  • Aktualizace dokumentace k rutinám PowerShellu v Graphu (Add/Remove ApplicationKey + ApplicationPassword) obsahuje příklady pro vrácení přihlašovacích údajů.
  • Přidejte do Prostředí Microsoft Graph PowerShell vlastní rutiny, 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. Po 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 chcete obnovitelně odstranit, nastavte monitorování v protokolech auditu Azure AD, abyste se dozvěděli, jestli se stav změní zpět na povolenou nebo obnovenou.

Protokolování pro povoleno:

  • Služba – základní adresář
  • Typ aktivity – Princip aktualizace služby
  • Kategorie – Správa aplikací
  • Iniciovaný (actor) – hlavní 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í
  • Iniciovaný (actor) – hlavní 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

Implementace služby Identity Protection pro identity úloh

Podezřelé přihlášení: Pokud detekce rizik indikuje neobvyklé vlastnosti nebo vzory přihlášení a neobvyklé přidání přihlašovacích údajů do aplikace OAuth, může to být indikátor ohrožení zabezpečení. Standardní hodnoty detekce chování při přihlašování mezi 2 a 60 dny a aktivuje se, pokud během následného přihlášení dojde k jedné nebo několika z následujících neznámých vlastností:

  • IP adresa / ASN
  • Cílový prostředek
  • Uživatelský agent
  • Změna hostování nebo hostování IP adres mimo hostování
  • Země IP adresy
  • Typ přihlašovacích údajů

Když se tato detekce aktivuje, účet se označí jako vysoké riziko, protože to může znamenat převzetí účtu pro aplikaci předmětu. Upozorňujeme, že legitimní změny konfigurace aplikace někdy tuto detekci aktivují.

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

Tato upozornění se zobrazují na portálu Identity Protection a dají se exportovat do nástrojů SIEM prostřednictvím rozhraní API služby Identity Protection.

Review risks and alerts in the Identity Protection portal

Podmíněný přístup pro identity rizikových ú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á". Mějte na paměti, že vynucení prostřednictvím podmíněného přístupu je v současné době omezeno pouze na aplikace s jedním tenantem.

Control user access based on conditional access policy

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 částiAplikace>Azure Active Directory> EnterpriseSouhlas a oprávnění>Souhlas uživatele.

Select Allow user consent for apps from the options

Pokud chcete zkontrolovat možnosti konfigurace, přečtěte si téma Konfigurace způsobu vyjádření souhlasu uživatelů 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 poskytnout možnost požádat o souhlas s aplikacemi a mít možnost kontroly správy, doporučuje se implementovat pracovní postup souhlasu správce. Postupujte podle kroků pracovního postupu souhlasu správce a nakonfigurujte ho ve vašem tenantovi.

U vysoce privilegovaných operací, jako je souhlas správce, máte definovanou strategii privilegovaného přístupu podle našich pokynů.

Souhlas s krokem založený na riziku pomáhá snížit ohrožení uživatelů škodlivými aplikacemi. Například žádosti o souhlas pro nově registrované aplikace s více tenanty, které nejsou ověřeny vydavatelem, a vyžadují jiná než základní oprávnění, se považují za riziková. Pokud se zjistí žádost o souhlas rizikového uživatele, vyžaduje žádost místo toho k vyjádření souhlasu správce "krok nahoru". Tato funkce kroku 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 nastavení konfigurace uvedené tady.

Reference

Další playbooky reakce na incidenty

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

Prostředky reakce na incidenty