Indagine sulle applicazioni compromesse e dannose

Questo articolo fornisce indicazioni sull'identificazione e l'analisi di attacchi dannosi su una o più applicazioni in un tenant del cliente. Le istruzioni dettagliate consentono di eseguire l'azione correttiva necessaria per proteggere le informazioni e ridurre al minimo i rischi aggiuntivi.

  • Prerequisiti: Vengono illustrati i requisiti specifici che è necessario completare prima di avviare l'indagine. Ad esempio, la registrazione che deve essere attivata, i ruoli e le autorizzazioni necessarie, tra le altre.
  • Workflow: Mostra il flusso logico da seguire per eseguire questa indagine.
  • Passaggi di indagine: include una guida dettagliata per questa indagine specifica.
  • Passaggi di contenimento: Contiene i passaggi per disabilitare le applicazioni compromesse.
  • Passaggi di ripristino: Contiene passaggi generali su come ripristinare/mitigare da un attacco dannoso alle applicazioni compromesse.
  • Riferimenti: Contiene altri materiali di lettura e riferimento.

Prerequisiti

Prima di avviare l'indagine, assicurarsi di disporre degli strumenti e delle autorizzazioni corretti per raccogliere informazioni dettagliate.

Strumenti necessari

Per un'analisi efficace, installare il modulo PowerShell seguente e il toolkit nel computer di indagine:

Flusso di lavoro

Diagramma di flusso dettagliato dei passaggi di indagine.

Procedura di indagine

Per questa indagine, si supponga di avere un'indicazione di una potenziale compromissione dell'applicazione sotto forma di report utente, esempio di log di accesso di Microsoft Entra o un rilevamento di Identity Protection. Assicurati di completare e abilitare tutti i passaggi necessari dei prerequisiti.

Questo playbook viene creato con l'obiettivo di garantire che non tutti i clienti Microsoft e i team di indagine abbiano la suite completa di Microsoft 365 E5 o la suite di licenze Microsoft Entra ID P2 disponibili o configurati. Questo manuale evidenzia altre funzionalità di automazione quando opportuno.

Determinare il tipo di applicazione

È importante determinare il tipo di applicazione (multi o singolo tenant) nella fase di indagine per ottenere le informazioni corrette necessarie per contattare il proprietario dell'applicazione. Per altre informazioni, vedere Tenancy in Microsoft Entra ID.

Applicazioni multi-tenant

Per le applicazioni multi-tenant, l'applicazione è ospitata e gestita da terze parti. Identificare il processo necessario per contattare e segnalare i problemi al proprietario dell'applicazione.

Applicazioni a tenant singolo

Trovare i dettagli di contatto del proprietario dell'applicazione all'interno dell'organizzazione. È possibile trovarla nella scheda Proprietari della sezione Applicazioni aziendali . In alternativa, l'organizzazione potrebbe avere un database con queste informazioni.

È anche possibile eseguire questa query Microsoft Graph:

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

Controllare Identity Protection - Identità del carico di lavoro rischiose

Questa funzionalità è in anteprima al momento della scrittura di questo playbook e i requisiti di licenza si applicano al relativo utilizzo. Le identità del carico di lavoro rischiose possono essere il trigger per analizzare un Principal del servizio, ma possono anche essere usate per approfondire l'analisi di altri trigger che hai identificato. È possibile controllare lo stato Rischio di un'entità servizio utilizzando la scheda Protezione dell'identità - identità a rischio del carico di lavoro oppure utilizzare Microsoft API Graph. È anche possibile usare i prompt del linguaggio naturale per ottenere informazioni dettagliate sulle identità del carico di lavoro rischiose con Microsoft Security Copilot in Microsoft Entra.

Screenshot della pagina del portale Rilevamento dettagli rischi.

Screenshot dell'interfaccia utente dei dettagli rilevamento rischi.

Un esempio di rilevamento dei rischi del principale del servizio tramite API Graph.

Verificare la presenza di un comportamento di accesso insolito

Il primo passo dell'indagine consiste nel cercare prove di modelli di autenticazione insoliti nell'utilizzo del "Service Principal". All'interno del portale di Azure, Monitoraggio di Azure, Microsoft Sentinel o del sistema SIEM (Security Information and Event Management) di propria scelta, cercare quanto segue nella sezione Accessi dei principali del servizio:

  • Posizione: l'Entity Principal sta autenticandosi da posizioni\indirizzi IP inaspettati?
  • Errori: è presente un numero elevato di errori di autenticazione per il principale del servizio?
  • Marche temporali: esistono autenticazioni riuscite che si verificano in momenti inaspettati?
  • Frequenza: c'è un aumento della frequenza delle autenticazioni per il Service Principal?
  • Perdita di credenziali: le credenziali dell'applicazione sono hardcoded e pubblicate in un'origine pubblica, ad esempio GitHub?

Se hai distribuito Microsoft Entra ID Identity Protection - identità a rischio per il carico di lavoro, controlla le rilevazioni Accessi sospetti e Credenziali trapelate. Per altre informazioni, vedere Detenzioni dei rischi di identità del carico di lavoro.

Controllare la risorsa di destinazione

Nell'ambito degli accessi del Service Principal, controllare anche la risorsa a cui il Service Principal ha avuto accesso durante l'autenticazione. È importante ottenere il contributo dal proprietario dell'applicazione perché è familiare con le risorse a cui l'entità servizio dovrebbe accedere.

Screenshot di come controllare la risorsa del Principale del Servizio.

Verificare la presenza di modifiche delle credenziali anomale

Usare i log di controllo per ottenere informazioni sulle modifiche delle credenziali nelle applicazioni e nelle entità servizio. Filtrare per categoria in base alla gestione delle applicazioni e all'attività in base all'applicazione di aggiornamento: certificati e gestione dei segreti.

  • Verificare se al principale del servizio sono state assegnate credenziali nuove o inaspettate.
  • Verificare la presenza di credenziali nel principale del servizio tramite Microsoft API Graph.
  • Controllare sia l'applicazione che gli oggetti principali del servizio associati.
  • Controllare qualsiasi ruolo personalizzato creato o modificato. Si notino le autorizzazioni contrassegnate di seguito:

Screenshot di come controllare i ruoli personalizzati creati o modificati.

Se la governance delle app è stata distribuita in Microsoft Defender for Cloud Apps, controllare la presenza di avvisi relativi all'applicazione nel portale di Azure. Per altre informazioni, vedere Introduzione al rilevamento e alla correzione delle minacce delle app.

Se hai distribuito Identity Protection, controlla il report "Rilevamenti dei rischi" e la "cronologia dei rischi" nell'identità dell'utente o del carico di lavoro.

Screenshot dell'interfaccia utente del portale di rilevamento dei rischi.

Se hai distribuito Microsoft Defender for Cloud Apps, assicurati che il criterio "Aggiunta insolita di credenziali a un'app OAuth" sia abilitato e verifica la presenza di avvisi aperti.

Per altre informazioni, vedere Aggiunta insolita di credenziali a un'app OAuth.

È anche possibile eseguire una query sulle API servicePrincipalRiskDetections e riskDetections degli utenti per recuperare questi rilevamenti di rischio.

Cercare modifiche di configurazione dell'app anomale

  • Controllare le autorizzazioni API assegnate all'app per assicurarsi che le autorizzazioni siano coerenti con quanto previsto per l'app.
  • Controllare i log di controllo (filtrare l'Attività per Aggiorna applicazione o Aggiorna entità del servizio).
  • Verificare se le stringa di connessione sono coerenti e se l'URL di disconnessione è stato modificato.
  • Verificare se i domini nell'URL sono in linea con quelli registrati.
  • Determinare se qualcuno ha aggiunto un URL di reindirizzamento non autorizzato.
  • Confermare la proprietà dell'URI di reindirizzamento per assicurarsi che non sia scaduto e non sia stata richiesta da un avversario.

Inoltre, se è stata distribuita Microsoft Defender for Cloud Apps, controllare nel portale di Azure gli avvisi relativi all'applicazione attualmente in fase di analisi. Non tutti i criteri di avviso sono abilitati per impostazione predefinita per le app OAuth, quindi assicurarsi che questi criteri siano tutti abilitati. Per altre informazioni, vedere i criteri delle app OAuth. È anche possibile visualizzare informazioni sulla prevalenza delle app e sulle attività recenti nella scheda Indagine>App OAuth.

Verificare la presenza di ruoli di applicazioni sospetti

  • È anche possibile usare i log di controllo. Filtrare l'attività con l'aggiunta dell'assegnazione del ruolo dell'app all'entità servizio.
  • Verificare se i ruoli assegnati hanno privilegi elevati.
  • Verificare se questi privilegi sono necessari.

Verificare la presenza di app commerciali non verificate

  • Controllare se vengono usate applicazioni della galleria commerciale (versioni pubblicate e verificate).

Verificare la presenza di indicazioni sulla divulgazione delle informazioni relative a keyCredential

Rivedere il tenant di Azure per verificare potenziali rischi di divulgazione di informazioni sulle proprietà keyCredential, come descritto in CVE-2021-42306.

Per identificare e correggere le applicazioni Microsoft Entra interessate associate agli account di automazione Run-As interessati, navigare al repository GitHub delle linee guida per la correzione.

Importante

Se si individuano prove di compromissione, è importante eseguire i passaggi evidenziati nelle sezioni di contenimento e ripristino. Questi passaggi aiutano a risolvere il rischio, ma eseguono ulteriori indagini per comprendere l'origine della compromissione per evitare un ulteriore impatto e garantire che gli attori malintenzionati vengano rimossi.

Esistono due metodi principali per ottenere l'accesso ai sistemi tramite l'uso di applicazioni. Il primo implica il consenso di un'applicazione da parte di un amministratore o di un utente, in genere tramite un attacco di phishing. Questo metodo fa parte dell'accesso iniziale a un sistema ed è spesso definito "phishing del consenso".

Il secondo metodo implica un account amministratore già compromesso che crea una nuova app ai fini della persistenza, della raccolta dei dati e per rimanere sotto il radar. Ad esempio, un amministratore compromesso potrebbe creare un'app OAuth con un nome apparentemente innocuo, evitando il rilevamento e consentendo l'accesso a lungo termine ai dati senza la necessità di un account. Questo metodo è spesso visto negli attacchi statali nazionali.

Ecco alcuni dei passaggi che è possibile eseguire per approfondire l'analisi.

Controllare il registro di audit unificato di Microsoft 365 per le indicazioni di phishing degli ultimi sette giorni

In alcuni casi, quando gli utenti malintenzionati usano applicazioni dannose o compromesse come mezzo di persistenza o per esfiltrare i dati, è coinvolta una campagna di phishing. In base ai risultati dei passaggi precedenti, è necessario esaminare le identità di:

  • Proprietari dell'applicazione
  • Amministratori del consenso

Esaminare le identità per indicazioni sugli attacchi di phishing nelle ultime 24 ore. Aumentare questo intervallo di tempo se necessario a 7, 14 e 30 giorni se non sono presenti indicazioni immediate. Per un playbook dettagliato di investigazione del phishing, vedere il Phishing Investigation Playbook.

Cercare i consenso di applicazioni dannose negli ultimi sette giorni

Per fare aggiungere un'applicazione a un tenant, gli aggressori si spacciano per utenti o amministratori per ottenere il consenso per le applicazioni. Per saperne di più sui segni di un attacco, consultare il Playbook di indagine sulla concessione del consenso dell'applicazione (Application Consent Grant Investigation Playbook).

Controllare i log di controllo

Per visualizzare tutte le concessioni di consenso per tale applicazione, filtrare l'attività in base al consenso all'applicazione.

  • Utilizzare i registri di audit del Interfaccia di amministrazione di Microsoft Entra

  • Usare Microsoft Graph per eseguire query sui log di controllo

    a) Filtrare per un intervallo di tempo specifico:

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

b) Filtrare i log di controllo per le voci del log di controllo "Consent to Applications":

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) Usare Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Per altre informazioni, vedere il manuale di indagine sulla concessione del consenso dell'applicazione.

Un utente può autorizzare un'applicazione ad accedere ad alcuni dati nella risorsa protetta, fungendo da tale utente. Le autorizzazioni che consentono questo tipo di accesso sono denominate "autorizzazioni delegate" o consenso utente.

Per trovare le app concesse dagli utenti, usare LogAnalytics per eseguire ricerche nei log di controllo:

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

Controllare i log di controllo per verificare se le autorizzazioni concesse sono troppo ampie (a livello di tenant o con consenso amministratore)

La revisione delle autorizzazioni concesse a un'applicazione o a un'entità servizio può richiedere molto tempo. Inizia a comprendere le autorizzazioni potenzialmente rischiose in Microsoft Entra ID.

A questo scopo, seguire le indicazioni su come enumerare ed esaminare le autorizzazioni nell'indagine sulla concessione del consenso dell'app.

Controllare se le autorizzazioni sono state concesse dalle identità utente che non devono avere la possibilità di eseguire questa operazione o se le azioni sono state eseguite in date e ore strane

Esaminare l'utilizzo dei log di controllo:

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

È anche possibile usare i log di controllo Microsoft Entra, filtrare in base a Consenso all'applicazione. Nella sezione Dettagli del log di controllo, fare clic su Proprietà modificate e quindi esaminare ConsentAction.Permissions:

Screenshot su come utilizzare i registri di controllo di Microsoft Entra.

Fasi di contenimento

Dopo aver identificato una o più applicazioni o identità del carico di lavoro come dannose o compromesse, potrebbe non essere necessario eseguire immediatamente il rollback delle credenziali per questa applicazione, né eliminare immediatamente l'applicazione.

Importante

Prima di eseguire il passaggio seguente, l'organizzazione deve valutare l'impatto sulla sicurezza e l'impatto aziendale della disabilitazione di un'applicazione. Se l'impatto aziendale della disabilitazione di un'applicazione è troppo grande, prendere in considerazione la preparazione e il passaggio alla fase di ripristino di questo processo.

Disabilitare l'applicazione compromessa

Una tipica strategia di contenimento implica la disabilitazione degli accessi all'applicazione identificata, per dare al team di gestione degli incidenti o alla business unit interessata il tempo di valutare l'impatto dell'eliminazione o della rotazione delle chiavi. Se l'indagine ti porta a credere che anche le credenziali dell'account amministratore siano compromesse, questo tipo di attività deve essere coordinato con un evento di espulsione per garantire che tutte le vie per accedere al tenant vengano interrotte contemporaneamente.

Screenshot di come disattivare l'accesso utente.

È anche possibile usare il codice seguente Microsoft Graph PowerShell per disabilitare l'accesso all'app:

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

Procedura di ripristino

Correggere i Principal di Servizio

  1. Elenca tutte le credenziali assegnate all'Entità Servizio Rischiosa. Il modo migliore per eseguire questa operazione consiste nell'eseguire una chiamata Microsoft Graph usando GET ~/application/{id} dove ID passato è l'ID oggetto applicazione.

    • Analizzare l'output per le credenziali. L'output può contenere passwordCredentials o keyCredentials. Registrare i keyId per tutti.

      "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. Aggiungere una nuova credenziale del certificato (x509) all'oggetto applicazione usando l'API addKey dell'applicazione.

    POST ~/applications/{id}/addKey

  3. Rimuovere immediatamente tutte le credenziali precedenti. Per ogni vecchia credenziale della password, rimuoverla usando:

    POST ~/applications/{id}/removePassword

    Per ogni vecchia credenziale della chiave, la rimuova usando:

    POST ~/applications/{id}/removeKey

  4. Correggere tutti i principali del servizio associati all'applicazione. Seguire questo passaggio se il tenant ospita/registra un'applicazione multi-tenant e/o registra più entità servizio associate all'applicazione. Eseguire passaggi simili a quelli elencati in precedenza:

  • GET ~/servicePrincipals/{id}

  • Trovare passwordCredentials e keyCredentials nella risposta e quindi annotare tutti i keyId precedenti.

  • Rimuovere tutte le vecchie credenziali di password e chiave. Usa:

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

Correggere le risorse del Service Principal interessate

Rimediare ai segreti del KeyVault a cui l'entità servizio ha accesso ruotandoli, secondo la seguente priorità:

  • Segreti esposti direttamente con chiamate GetSecret .
  • Il resto dei segreti rimane nei KeyVaults esposti.
  • Il resto dei segreti distribuiti nelle sottoscrizioni vulnerabili.

Per altre informazioni, vedere Rimozione interattiva e rotazione dei certificati e dei segreti di un Principal del servizio o di un'applicazione.

Per indicazioni Microsoft Entra SecOps sulle applicazioni, vedere Microsoft Entra Guida alle operazioni di sicurezza per le applicazioni.

In ordine di priorità, questo scenario sarà:

  • Aggiornare i cmdlet di Graph PowerShell (Add/Remove ApplicationKey + ApplicationPassword) per includere esempi per la rotazione delle credenziali.
  • Aggiungere cmdlet personalizzati a Microsoft Graph PowerShell che semplifica questo scenario.

Disabilitare o eliminare applicazioni dannose

Un'applicazione può essere disabilitata o eliminata. Per disabilitare l'applicazione, in Abilitato per consentire agli utenti di accedere, spostare l'interruttore su No.

È possibile eliminare l'applicazione, temporaneamente o definitivamente, nel portale di Azure o tramite Microsoft API Graph. Quando si elimina leggero, l'applicazione può essere ripristinata fino a 30 giorni dopo l'eliminazione.

DELETE /applications/{id}

Per eliminare definitivamente l'applicazione, usare questa chiamata a Microsoft API Graph:

DELETE /directory/deletedItems/{id}

Se si disabilita o si elimina temporaneamente l'applicazione, configurare il monitoraggio nei log di controllo Microsoft Entra per sapere se lo stato cambia di nuovo in abilitato o ripristinato.

Registrazione abilitata per:

  • Service - Core Directory
  • Tipo di attività - Aggiornamento del principal del servizio
  • Categoria - Gestione applicazioni
  • Avviato da (attore) - UPN dell'attore
  • Target - ID app e nome visualizzato
  • Proprietà modificate - Nome proprietà = account abilitato, nuovo valore = true

Registrazione per il ripristino:

  • Service - Core Directory
  • Tipo di attività - Aggiungi il principale del servizio
  • Categoria - Gestione applicazioni
  • Avviato da (attore) - UPN dell'attore
  • Obiettivi - ID app e nome visualizzato
  • Proprietà modificate - Nome proprietà = account abilitato, nuovo valore = true

Nota

Microsoft a livello globale disabilita le applicazioni che violano le condizioni per il servizio. In questi casi, queste applicazioni mostrano DisabledDueToViolationOfServicesAgreement nella proprietà disabledByMicrosoftStatus sui tipi di risorse correlati application e service principal in Microsoft Graph. Per impedire che vengano nuovamente istanziate nella tua organizzazione in futuro, non puoi eliminare questi oggetti.

Implementare Identity Protection per le identità dei carichi di lavoro

Microsoft rileva il rischio per le identità dei carichi di lavoro in base al comportamento di accesso e agli indicatori offline di compromissione.

Per ulteriori informazioni, vedere Protezione delle identità dei carichi di lavoro con Identity Protection.

Questi avvisi vengono visualizzati nel portale di Identity Protection e possono essere esportati in strumenti SIEM tramite le impostazioni di diagnostica o le API di Identity Protection.

Screenshot di come esaminare i rischi e gli avvisi nel portale di Identity Protection.

Accesso condizionale per identità di carichi di lavoro a rischio

L'accesso condizionale consente di bloccare l'accesso per account specifici designati quando Identity Protection li contrassegna come "a rischio". L'imposizione tramite l'accesso condizionale è attualmente limitata solo alle applicazioni a tenant singolo.

Screenshot di come controllare l'accesso degli utenti in base ai criteri di accesso condizionale.

Per altre informazioni, vedere Accesso condizionale per le identità del carico di lavoro.

Implementare i criteri di rischio delle applicazioni

Esaminare le impostazioni di consenso utente in Microsoft Entra ID>Applicazioni aziendali>Consent e autorizzazioni>Impostazioni di consenso utente.

Screenshot di come consentire il consenso dell'utente per le app.

Per esaminare le opzioni di configurazione, vedere Configurare il consenso degli utenti per le app.

Quando uno sviluppatore di applicazioni indirizza gli utenti all'endpoint di consenso amministratore con la finalità di fornire il consenso per l'intero tenant, è noto come flusso di consenso amministratore. Per garantire il corretto funzionamento del flusso di consenso amministratore, gli sviluppatori di applicazioni devono elencare tutte le autorizzazioni nella proprietà RequiredResourceAccess nel manifesto dell'applicazione.

La maggior parte delle organizzazioni disabilita la possibilità per gli utenti di fornire il consenso alle applicazioni. Per consentire agli utenti di richiedere comunque il consenso per le applicazioni e avere funzionalità di revisione amministrativa, è consigliabile implementare il flusso di lavoro di consenso amministratore. Seguire i passaggi del flusso di lavoro del consenso amministratore per configurarlo nel tenant.

Per operazioni con privilegi elevati, ad esempio il consenso dell'amministratore, è necessario definire una strategia di accesso con privilegi nelle linee guida.

Il consenso dettagliato basato sul rischio consente di ridurre l'esposizione degli utenti ad app dannose. Ad esempio, le richieste di consenso per le app multi-tenant appena registrate che non sono verificate dall'editore e richiedono autorizzazioni non di base sono considerate rischiose. Se viene rilevata una richiesta di consenso utente rischiosa, la richiesta richiede invece un "passaggio" per il consenso dell'amministratore. Questa funzionalità avanzata è abilitata per impostazione predefinita, ma comporta una modifica del comportamento solo quando il consenso dell'utente è abilitato.

Assicurarsi che sia abilitato nel tenant ed esaminare le impostazioni di configurazione descritte qui.

Riferimenti

Playbook aggiuntivi per la risposta agli eventi imprevisti

Esaminare le linee guida per identificare e analizzare questi tipi aggiuntivi di attacchi:

Risorse di risposta agli eventi imprevisti

  • Last updated on