Condividi tramite

Indagine sulla concessione del consenso dell'app

  • Articolo

Questo articolo fornisce indicazioni sull'identificazione e l'analisi degli attacchi di consenso delle app, sulla protezione delle informazioni e sulla riduzione dei rischi aggiuntivi.

In questo articolo sono contenute le sezioni seguenti:

  • Prerequisiti: copre 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.
  • Flusso di lavoro: mostra il flusso logico da seguire per eseguire questa indagine.
  • Elenco di controllo: contiene un elenco di attività per ognuno dei passaggi del grafico di flusso. Questo elenco di controllo può essere utile in ambienti altamente regolamentati per verificare i passaggi eseguiti o semplicemente come controllo qualità per se stessi.
  • Passaggi di indagine: include una guida dettagliata per questa indagine specifica.
  • Ripristino: contiene passaggi generali su come ripristinare/mitigare da un attacco di concessione del consenso dell'applicazione illecita.
  • Riferimenti: contiene altri materiali di lettura e riferimento.

Prerequisiti

Di seguito sono riportate le impostazioni generali e le configurazioni da completare durante l'esecuzione di un'indagine per le concessioni di consenso dell'applicazione. Prima di avviare l'indagine, assicurarsi di leggere i tipi di autorizzazioni di consenso illustrati in Tipi di autorizzazione di consenso.

Dati cliente

Per avviare il processo di indagine, sono necessari i dati seguenti:

  • Dettaglio degli indicatori di compromissione (IoC)
  • Data e ora in cui si è notato l'evento imprevisto
  • Intervallo di date
  • Numero di account compromessi
  • Nome degli account compromessi
  • Ruoli dell'account compromesso
  • Gli account hanno privilegi elevati (GA Microsoft Exchange, SharePoint)?
  • Sono presenti applicazioni aziendali correlate all'evento imprevisto?
  • Gli utenti segnalavano le applicazioni che richiedevano autorizzazioni per i dati per loro conto?

Requisiti di sistema

Assicurarsi di completare le installazioni e i requisiti di configurazione seguenti:

  • Il modulo AzureAD PowerShell è installato.
  • Si dispone dei diritti di amministratore globale nel tenant in cui viene eseguito lo script.
  • È stato assegnato il ruolo di amministratore locale nel computer usato per eseguire gli script.

Nota

I moduli Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per maggiori informazioni, leggere l'aggiornamento sulla deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza alla migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, consultare le Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

Installare il modulo AzureAD

Usare questo comando per installare il modulo AzureAD.

Install-Module -Name AzureAD -Verbose

Nota

Se viene richiesto di installare i moduli da un repository non attendibile, digitare Y e premere INVIO.

Installare il modulo MSOnline PowerShell

  1. Eseguire l'app Windows PowerShell con privilegi elevati (esegui come amministratore).

  2. Eseguire questo comando per consentire a PowerShell di eseguire script firmati.

    Set-ExecutionPolicy RemoteSigned

  3. Installare il modulo MSOnline con questo comando.

    Install-Module -Name MSOnline -Verbose

    Nota

    Se viene richiesto di installare i moduli da un repository non attendibile, digitare Y e premere INVIO.

Scaricare lo script AzureADPSPermissions da GitHub

  1. Scaricare lo script Get-AzureADPSPermissions.ps1 da GitHub in una cartella da cui si esegue lo script. Anche il file di output "permissions.csv" viene scritto nella stessa cartella.

  2. Aprire un'istanza di PowerShell come amministratore e aprire la cartella in cui è stato salvato lo script.

  3. Connettersi alla directory usando il Connect-AzureAD cmdlet . Ecco un esempio.

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

  4. Eseguire questo comando di PowerShell.

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

    Disconnettere la sessione di AzureAD con questo comando.

    Disconnect-AzureAD

Il consenso è il processo di concessione dell'autorizzazione a un'applicazione per accedere alle risorse protette per conto degli utenti. È possibile richiedere il consenso di un amministratore o di un utente per consentire l'accesso ai dati dell'organizzazione o dei singoli utenti.

A un'applicazione viene concesso l'accesso ai dati in base a un determinato utente o per l'intera organizzazione. Gli utenti malintenzionati possono usare in modo improprio questi consensi per ottenere la persistenza all'ambiente e accedere ai dati sensibili. Questi tipi di attacchi sono denominati concessioni di consenso illecite, che possono verificarsi tramite un messaggio di posta elettronica di phishing, una compromissione dell'account utente tramite password spraying o quando un utente malintenzionato registra un'applicazione come utente legittimo. Negli scenari in cui un account amministratore viene compromesso, la registrazione e la concessione del consenso sono per l'intero tenant e non solo per un utente.

Prima che un'applicazione possa accedere ai dati dell'organizzazione, un utente deve concedere le autorizzazioni dell'applicazione a tale scopo. Autorizzazioni diverse consentono livelli di accesso diversi. Per impostazione predefinita, tutti gli utenti possono fornire il consenso alle applicazioni per le autorizzazioni che non richiedono il consenso dell'amministratore. Ad esempio, per impostazione predefinita, un utente può fornire il consenso per consentire a un'app di accedere alla cassetta postale, ma non può fornire il consenso per consentire a un'app di accedere in lettura e scrittura a tutti i file dell'organizzazione.

Nota

Con la possibilità di concedere alle app l'accesso ai dati, gli utenti possono acquisire facilmente applicazioni utili ed essere produttivi. Tuttavia, in alcune situazioni, questa configurazione può rappresentare un rischio se non viene monitorata e controllata attentamente.

Per poter concedere il consenso amministratore a livello di tenant, è necessario accedere con almeno uno dei ruoli seguenti:

  • Amministratore applicazione
  • Amministratore di applicazioni cloud
  • Amministratore: indica che il consenso è stato fornito dall'amministratore (per conto dell'organizzazione)
  • Singolo utente: indica che il consenso è stato concesso dall'utente e ha accesso solo alle informazioni dell'utente
  • Valori accettati
    • AllPrincipals - Consenso da parte di un amministratore per l'intero tenancy
    • Entità: consenso da parte dell'utente singolo per i dati correlati solo a tale account

L'esperienza utente effettiva di concessione del consenso varia a seconda dei criteri impostati nel tenant dell'utente, dell'ambito dell'autorità o del ruolo dell'utente e del tipo di autorizzazioni richieste dall'applicazione client. In altre parole, l'esperienza di consenso ricade in parte sotto il controllo degli sviluppatori di applicazioni e degli amministratori del tenant. Gli amministratori hanno la flessibilità di impostare e disattivare i criteri in un tenant o in un'app per controllare l'esperienza di consenso nel tenant. Gli sviluppatori di applicazioni possono determinare quali tipi di autorizzazioni sono richiesti e se vogliono guidare gli utenti attraverso il flusso di consenso utente o il flusso di consenso amministratore.

  • Flusso di consenso utente: quando uno sviluppatore di applicazioni indirizza gli utenti all'endpoint di autorizzazione con la finalità di registrare il consenso solo per l'utente corrente.

  • Flusso di consenso amministratore: quando uno sviluppatore di applicazioni indirizza gli utenti all'endpoint di consenso amministratore con lo scopo di registrare il consenso per l'intero tenant. 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.

Autorizzazioni delegate e autorizzazioni dell'applicazione

Le autorizzazioni delegate vengono usate dalle app che dispongono di un utente connesso e possono avere il consenso applicato dall'amministratore o dall'utente.

Le autorizzazioni dell'applicazione vengono usate dalle app eseguite senza un utente connesso. Ad esempio, le app eseguite come servizi in background o daemon. Le autorizzazioni dell'applicazione possono essere concesse solo da un amministratore.

Per altre informazioni, vedi:

Classificazione delle autorizzazioni rischiose

Ci sono migliaia (almeno) di autorizzazioni nel sistema, e non è possibile elencare o analizzare tutti questi elementi. L'elenco seguente illustra le autorizzazioni comunemente usate in modo improprio e altri utenti che potrebbero creare un impatto irreversibile se usato in modo improprio.

A livello generale, Microsoft ha osservato le seguenti autorizzazioni delegate "radice" (App+Utente) usate in modo improprio negli attacchi di phishing di consenso. Radice equivale al livello superiore. Ad esempio, Contacts.* indica di includere tutte le permutazioni delegate delle autorizzazioni contatti: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared e Contacts.ReadWrite.Shared.

  1. Mail.* (incluso Mail.Send*, ma non Mail.ReadBasic*)
  2. Contatti. *
  3. MailboxSettings.*
  4. Gente.*
  5. file.*
  6. Note.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Le prime sette autorizzazioni nell'elenco precedente sono relative a Microsoft Graph e agli equivalenti api "legacy", ad esempio Azure Active Directory (Azure AD) Graph e Outlook REST. L'ottava autorizzazione è per Azure Resource Manager (ARM) e potrebbe anche essere pericolosa in qualsiasi API che espone dati sensibili con questo ambito di rappresentazione generale.

In base alle osservazioni del team di risposta agli eventi imprevisti Microsoft, gli utenti malintenzionati usano una combinazione delle prime sei autorizzazioni nel 99% degli attacchi di phishing di consenso. La maggior parte delle persone non considera la versione delegata di Mail.Read o Files.Read come autorizzazione ad alto rischio, tuttavia, gli attacchi sono in genere diffusi e destinati agli utenti finali, invece di lancia phishing contro gli amministratori che possono effettivamente fornire il consenso alle autorizzazioni pericolose. È consigliabile bollare le app con questi livelli di autorizzazioni di impatto "critiche". Anche se le applicazioni non hanno finalità dannose e se un attore malintenzionato dovesse compromettere l'identità dell'app, l'intera organizzazione potrebbe essere a rischio.

Per le autorizzazioni con maggiore impatto sul rischio, iniziare da qui:

  • Autorizzazioni dell'applicazione (AppOnly/AppRole) di tutte le autorizzazioni precedenti, se applicabile

Versioni delegate e AppOnly delle autorizzazioni seguenti:

  • 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
  • Tutte le altre autorizzazioni AppOnly che consentono l'accesso in scrittura

Per l'elenco delle autorizzazioni con impatto sul rischio più basso, iniziare da qui:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • E-mail
  • Profilo
  • Offline_access (solo se abbinato ad altre autorizzazioni per questo elenco di rischi più basso)

Visualizzazione delle autorizzazioni

  1. Per visualizzare le autorizzazioni, passare alla schermata Registrazione nell'applicazione aziendale.

    Screenshot di come visualizzare autorizzazioni diverse.

  2. Selezionare Visualizza autorizzazioni API.

    Screenshot di come visualizzare e aggiungere autorizzazioni API.

  3. Selezionare Aggiungi un'autorizzazione e viene visualizzata la schermata seguente.

    Screenshot di come richiedere autorizzazioni API.

  4. Selezionare Microsoft Graph per visualizzare i diversi tipi di autorizzazioni.

    Screenshot di diversi tipi di autorizzazioni API.

  5. Selezionare il tipo di autorizzazioni in uso per l'applicazione registrata: autorizzazioni delegate o autorizzazioni dell'applicazione. Nell'immagine precedente è selezionata l'opzione Autorizzazioni dell'applicazione.

  6. È possibile cercare una delle autorizzazioni ad alto rischio, ad esempio EduRoster.

    Screenshot di una richiesta di autorizzazione API di esempio.

  7. Selezionare EduRoster ed espandere le autorizzazioni.

    Screenshot di un elemento di autorizzazione API con una descrizione comando.

  8. È ora possibile assegnare o esaminare queste autorizzazioni.

    Per altre informazioni, Graph Permissions.For more information, Graph Permissions.

Workflow

[Diagramma di flusso di un flusso di lavoro di analisi delle concessioni di consenso dell'app.]

È anche possibile:

  • Scaricare la concessione del consenso dell'app e altri flussi di lavoro del playbook di risposta agli eventi imprevisti come PDF.
  • Scaricare i flussi di lavoro del playbook di concessione del consenso dell'app e altri flussi di lavoro del playbook di risposta agli eventi imprevisti come file di Visio.

Elenco di controllo

Usare questo elenco di controllo per eseguire la convalida della concessione del consenso dell'applicazione.

  • Indicatori di compromissione (IoC)

    Controllare gli indicatori seguenti di compromissione (IoC):

    • Quando hai notato l'incidente?
    • Intervallo di date dell'evento imprevisto (quanto a sinistra è il post obiettivo?)
    • Numero di account compromessi
    • Nomi di account compromessi
    • Ruoli degli account compromessi
    • Gli account compromessi hanno privilegi elevati, un utente standard o una combinazione

  • ruoli

    È necessario essere assegnati con questi ruoli:

    • Ruolo Amministratore locale nel computer da cui si esegue lo script

  • Configurazione di PowerShell

    Configurare l'ambiente PowerShell con questa procedura:

    1. Installare il modulo Azure AD PowerShell.
    2. Eseguire l'app Windows PowerShell con privilegi elevati. (Esegui come amministratore).
    3. Configurare PowerShell per l'esecuzione di script firmati.
    4. Scaricare lo script Get-AzureADPSPermissions.ps1 .

  • Trigger di indagine

    • Compromissione dell'account
    • Impostazioni di consenso dell'app modificate nel tenant
    • Rilevato motivo dello stato dell'evento di avviso/controllo "applicazione rischiosa"
    • Si è notato un aspetto strano delle applicazioni

È anche possibile scaricare la concessione del consenso dell'app e altri elenchi di controllo del playbook per eventi imprevisti come file di Excel.

Procedura di indagine

È possibile usare i due metodi seguenti per analizzare le concessioni di consenso dell'applicazione:

  • Portale di Azure
  • Script di PowerShell

Nota

L'uso del portale di Azure consente solo di visualizzare le concessioni di consenso amministratore per gli ultimi 90 giorni e, in base a questo, è consigliabile usare il metodo di script di PowerShell solo per ridurre i passaggi di indagine da parte dell'utente malintenzionato.

Metodo 1: uso del portale di Azure

È possibile usare l'interfaccia di amministrazione di Microsoft Entra per trovare le applicazioni concesse ai singoli utenti.

  1. Accedi al portale di Azure come amministratore.
  2. Selezionare l'icona Microsoft Entra ID .Select the Microsoft Entra ID icon.
  3. Seleziona Utenti.
  4. Selezionare l'utente da rivedere.
  5. Selezionare Applicazioni.
  6. È possibile visualizzare l'elenco delle app assegnate all'utente e le autorizzazioni di queste applicazioni.

Metodo 2 - Uso di PowerShell

Esistono diversi strumenti di PowerShell che è possibile usare per analizzare le concessioni di consenso illecite, ad esempio:

PowerShell è lo strumento più semplice e non richiede di modificare nulla nella tenancy. Baseremo l'indagine sulla documentazione pubblica dell'attacco di concessione del consenso illecito.

Eseguire Get-AzureADPSPermissions.ps1per esportare tutte le concessioni di consenso OAuth e le app OAuth per tutti gli utenti nel tenancy in un file .csv . Vedere la sezione Prerequisiti per scaricare ed eseguire lo Get-AzureADPSPermissions script.

  1. Aprire un'istanza di PowerShell come amministratore e aprire la cartella in cui è stato salvato lo script.

  2. Connettersi alla directory usando il comando Connect-AzureAD seguente. Ecco un esempio.

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

  3. Eseguire questo comando di PowerShell.

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

  4. Al termine dello script, è consigliabile disconnettere la sessione di Microsoft Entra con questo comando.

     Disconnect-AzureAD

    Nota

    Il completamento dello script potrebbe richiedere ore, a seconda delle dimensioni e delle autorizzazioni configurate, nonché della connessione.

  5. Lo script crea un file denominato Permissions.csv.

  6. Aprire il file, quindi filtrare o formattare i dati in una tabella e salvarli .xlxs come file.

    Le intestazioni di colonna per l'output sono visualizzate in questa immagine.

    Screenshot delle intestazioni di colonna di Excel.

  7. Nella colonna ConsentType (G) cercare il valore AllPrinciples. L'autorizzazione AllPrincipals consente all'applicazione client di accedere al contenuto di tutti i membri della tenancy. Le applicazioni native di Microsoft 365 necessitano di questa autorizzazione per funzionare correttamente. Ogni applicazione non Microsoft con questa autorizzazione deve essere esaminata attentamente.

  8. Nella colonna Autorizzazione (F) esaminare le autorizzazioni di ogni applicazione delegata. Cercare l'autorizzazione Lettura e scrittura o *. Tutte le autorizzazioni ed esaminare attentamente queste autorizzazioni perché potrebbero non essere appropriate. Screenshot delle autorizzazioni dell'app nella colonna F.

    Nota

    Esaminare gli utenti specifici con consenso concesso. Se agli utenti con un profilo elevato o ad alto impatto sono concessi consensi inappropriati, è consigliabile esaminare ulteriormente.

  9. Nella colonna ClientDisplayName (C)cercare le app che sembrano sospette, ad esempio:

    • App con nomi con errori di ortografia Screenshot di un nome con errori di ortografia.

    • Nomi insoliti o bland Screenshot di un nome insolito.

    • Nomi che suonano hacker. È necessario esaminare attentamente questi nomi. Screenshot di un nome hacker.

Output di esempio: AllPrincipals e leggi tutto. Le applicazioni potrebbero non avere elementi sospetti, ad esempio nomi bland e usano il grafo MS. Tuttavia, eseguire ricerche e determinare lo scopo delle applicazioni e le autorizzazioni effettive che le applicazioni hanno nel tenant, come illustrato in questo esempio.

Screenshot dell'esempio di applicazioni con ConsentType AllPrincipals.

Ecco alcuni suggerimenti utili per esaminare le indagini sui criteri di sicurezza delle informazioni :Here are some useful tips to review information security policy (ISP) investigations:

  • ReplyURL/RedirectURL
    • Cercare URL sospetti
  • L'URL è ospitato in un dominio sospetto?
    • È compromesso?
    • Il dominio è registrato di recente?
    • Si tratta di un dominio temporaneo?
  • Nella registrazione dell'app sono presenti condizioni per il servizio o il contratto di servizio?
  • Il contenuto è univoco e specifico per l'applicazione/autore?
  • Il tenant che ha registrato l'applicazione appena creata o compromessa (ad esempio, l'app è registrata da un utente a rischio)?

Tecniche di attacco

Anche se ogni attacco tende a variare, le tecniche di attacco principali sono:

  • Un utente malintenzionato registra un'app con un provider OAuth 2.0, ad esempio Microsoft Entra ID.

  • Le applicazioni vengono configurate in modo da renderle legittime. Ad esempio, gli utenti malintenzionati potrebbero usare il nome di un prodotto diffuso disponibile nello stesso ecosistema.

  • L'utente malintenzionato ottiene un collegamento direttamente dagli utenti, che possono essere eseguiti tramite phishing convenzionale basato su posta elettronica, compromettendo un sito Web nonmalicio o tramite altre tecniche.

  • L'utente seleziona il collegamento e viene visualizzata una richiesta di consenso autentica che chiede di concedere le autorizzazioni per l'app dannosa ai dati.

  • Se un utente seleziona "Accetta", concede all'app le autorizzazioni per accedere ai dati sensibili.

  • L'app ottiene un codice di autorizzazione, che riscatta per un token di accesso e potenzialmente un token di aggiornamento.

  • Il token di accesso viene usato per effettuare chiamate API per conto dell'utente.

  • Se l'utente accetta, l'utente malintenzionato può accedere ai messaggi di posta elettronica dell'utente, alle regole di inoltro, ai file, ai contatti, alle note, al profilo e ad altre risorse e dati sensibili.

    Screenshot dell'esempio di richiesta di autorizzazioni.

Ricerca di segni di un attacco

  1. Nel portale di Microsoft 365 Defender in https://security.microsoft.compassare a Controlla. In alternativa, per passare direttamente alla pagina Controllo , usare https://security.microsoft.com/auditlogsearch.

  2. Nella pagina Controllo cercare tutte le attività e tutti gli utenti, immettere la data di inizio e la data di fine, se necessario, e quindi selezionare Cerca.

    Screenshot di esempio di una ricerca nel log di controllo.

  3. Selezionare Filtra risultati e nel campo Attività immettere Consent to application (Consent to application).

    Screenshot dell'esempio di filtro di una ricerca nel log di controllo.

  4. Se si dispone di attività con il consenso per concedere, continuare con il passaggio successivo.

  5. Selezionare il risultato per visualizzare i dettagli dell'attività. Selezionare Altre informazioni per ottenere i dettagli dell'attività.

  6. Controllare se IsAdminContent è impostato su "True".

    Nota

    Questo processo può richiedere da 30 minuti fino a 24 ore affinché la voce corrispondente del log di controllo venga visualizzata nei risultati della ricerca dopo che si verifica un evento.

    La quantità di tempo in cui un record di controllo viene conservato ed è ricercabile nel log di controllo dipende dall'abbonamento a Microsoft 365 e in particolare dal tipo di licenza assegnato a un utente specifico. Se questo valore è true, indica che un utente potrebbe aver concesso un accesso ampio ai dati. In caso di imprevisto, eseguire azioni immediate per confermare un attacco.

Come confermare un attacco?

Se in precedenza sono elencate una o più istanze degli IoC, è necessario eseguire ulteriori indagini per confermare positivamente che si è verificato l'attacco.

Inventariare le app con accesso nell'organizzazione

È possibile inventariare le app per gli utenti usando l'interfaccia di amministrazione di Microsoft Entra, PowerShell o fare in modo che gli utenti enumerino singolarmente l'accesso alle applicazioni.

  • Usare l'interfaccia di amministrazione di Microsoft Entra per inventariare le applicazioni e le relative autorizzazioni. Questo metodo è completo, ma è possibile controllare un solo utente alla volta, che può richiedere molto tempo se è necessario controllare le autorizzazioni di più utenti.
  • Usare PowerShell per inventariare le applicazioni e le relative autorizzazioni. Questo metodo è il più veloce e più accurato, con il minor sovraccarico.
  • Incoraggiare gli utenti a controllare singolarmente le app e le autorizzazioni e segnalare i risultati agli amministratori per la correzione.

Inventario delle app assegnate agli utenti

È possibile usare l'interfaccia di amministrazione di Microsoft Entra per visualizzare l'elenco delle app a cui i singoli utenti hanno concesso le autorizzazioni.

  1. Accedere al portale di Azure con diritti amministrativi.
  2. Selezionare l'icona Microsoft Entra ID .Select the Microsoft Entra ID icon.
  3. Seleziona Utenti.
  4. Selezionare l'utente da rivedere.
  5. Selezionare Applicazioni.

È possibile visualizzare l'elenco delle app assegnate all'utente e le autorizzazioni concesse a queste app.

Determinare l'ambito dell'attacco

Dopo aver completato l'accesso all'applicazione di inventario, esaminare il log di controllo per determinare l'ambito completo della violazione. Cercare gli utenti interessati, gli intervalli di tempo a cui l'applicazione illecita aveva accesso all'organizzazione e le autorizzazioni che l'app aveva. È possibile eseguire ricerche nel log di controllo in Microsoft 365 Security & Portale di conformità di Microsoft Purview s.

Importante

Se il controllo non è stato abilitato prima del possibile attacco, non sarà possibile analizzare perché i dati di controllo non sono disponibili.

Come prevenire gli attacchi e attenuare i rischi?

Se l'organizzazione dispone della licenza appropriata:

  • Usare altre funzionalità di controllo delle applicazioni OAuth nelle app di Microsoft Defender per il cloud.
  • Usare cartelle di lavoro di Monitoraggio di Azure per monitorare le autorizzazioni e l'attività correlata al consenso. La cartella di lavoro Informazioni dettagliate sul consenso offre una visualizzazione delle app in base al numero di richieste di consenso non riuscite. Ciò può essere utile per classificare in ordine di priorità le applicazioni che gli amministratori devono esaminare e decidere se concedere loro il consenso amministratore.

Dopo aver identificato un'applicazione con autorizzazioni illecite, disabilitare immediatamente l'applicazione seguendo le istruzioni riportate in Disabilitare un'applicazione. Contattare quindi supporto tecnico Microsoft per segnalare l'applicazione dannosa.

Una volta disabilitata un'applicazione in Microsoft Entra, non può ottenere nuovi token per accedere ai dati e altri utenti non possono accedere o concedere il consenso all'app.

Nota

Se si sospetta che sia stata rilevata un'applicazione dannosa nell'organizzazione, è preferibile disabilitarla piuttosto che eliminarla. Se si elimina solo l'applicazione, potrebbe essere restituita in un secondo momento se un altro utente concede il consenso. Disabilitare invece l'applicazione per assicurarsi che non possa tornare in un secondo momento.

Procedura per proteggere l'organizzazione

Esistono diversi tipi di attacco di consenso, queste difese consigliate attenuano tutti i tipi di attacchi, in particolare il phishing del consenso, in cui gli utenti malintenzionati ingannano gli utenti a concedere a un'app dannosa l'accesso a dati sensibili o ad altre risorse. Invece di tentare di rubare la password dell'utente, un utente malintenzionato sta cercando l'autorizzazione per un'app controllata dall'utente malintenzionato per accedere a dati preziosi.

Per evitare che gli attacchi di consenso influiscano sull'ID Microsoft Entra e Office 365, vedere le raccomandazioni seguenti:

Impostare i criteri

  • Questa impostazione ha implicazioni utente e potrebbe non essere applicabile per un ambiente. Se si intende consentire qualsiasi consenso, assicurarsi che gli amministratori approvino le richieste.

  • Consenti il consenso per le applicazioni provenienti solo da autori verificati e tipi specifici di autorizzazioni classificate come a basso impatto.

    Nota

    Le raccomandazioni precedenti sono suggerite in base alle configurazioni più ideali e sicure. Tuttavia, poiché la sicurezza è un buon equilibrio tra funzionalità e operazioni, le configurazioni più sicure potrebbero causare un sovraccarico maggiore per gli amministratori. È una decisione migliore dopo aver consultato gli amministratori.

    Configurare il consenso dettagliato basato sul rischio : abilitato per impostazione predefinita se il consenso dell'utente per le concessioni è abilitato

  • Il consenso incrementale basato sul rischio consente di ridurre l'esposizione degli utenti ad app dannose che effettuano richieste di consenso illecite. Se Microsoft rileva una richiesta di consenso dell'utente finale rischiosa, la richiesta richiede invece un "passaggio" per il consenso dell'amministratore. Questa funzionalità è abilitata per impostazione predefinita, ma comporta solo una modifica del comportamento quando è abilitato il consenso dell'utente finale.

  • Quando viene rilevata una richiesta di consenso rischiosa, la richiesta di consenso visualizza un messaggio che indica che è necessaria l'approvazione dell'amministratore. Se il flusso di lavoro della richiesta di consenso amministratore è abilitato, l'utente può inviare la richiesta all'amministratore per ulteriori verifiche direttamente dalla richiesta di consenso. Se abilitata, viene visualizzato il messaggio seguente:

    AADSTS90094: <clientAppDisplayName> richiede l'autorizzazione per accedere alle risorse dell'organizzazione che possono concedere solo un amministratore. Prima di usarla, è necessario chiedere a un amministratore di concedere l'autorizzazione a quest'app. In questo caso, verrà registrato anche un evento di controllo con una categoria "ApplicationManagement" Tipo di attività "Consent to application" e Status Reason of "Risky application detected" (Motivo dello stato dell'applicazione rischiosa rilevata).

Nota

Tutte le attività che richiedono l'approvazione dell'amministratore comportano un sovraccarico operativo. Le impostazioni di consenso e consenso utente sono attualmente disponibili in anteprima. Quando è pronta per la disponibilità generale (GA), la funzionalità "Consenti il consenso utente dagli editori verificati, per le autorizzazioni selezionate" dovrebbe ridurre il sovraccarico degli amministratori ed è consigliabile per la maggior parte delle organizzazioni.

Screenshot dell'esempio di autorizzazioni di consenso.

Informare gli sviluppatori di applicazioni di seguire l'ecosistema di app attendibile. Per aiutare gli sviluppatori a creare integrazioni di alta qualità e sicurezza, stiamo annunciando anche l'anteprima pubblica di Integration Assistant nelle registrazioni dell'app Microsoft Entra.

  • Integration Assistant analizza la registrazione dell'app e ne esegue il benchmark rispetto a un set di procedure consigliate per la sicurezza.
  • Integration Assistant evidenzia le procedure consigliate rilevanti durante ogni fase del ciclo di vita dell'integrazione, dallo sviluppo fino al monitoraggio, e garantisce che ogni fase sia configurata correttamente.
  • Semplifica il lavoro, indipendentemente dal fatto che tu stia integrando la tua prima app o sei un esperto che sta cercando di migliorare le tue competenze.

Informare l'organizzazione sulle tattiche di consenso (tattiche di phishing, amministratore e consenso utente):

  • Verificare la presenza di errori ortografici e grammaticali. Se un messaggio di posta elettronica o la schermata di consenso dell'applicazione presenta errori ortografici e grammaticali, è probabile che si tratti di un'applicazione sospetta.
  • Tenere d'occhio i nomi delle app e gli URL di dominio. Gli utenti malintenzionati amano spoofare nomi di app che lo rendono apparentemente proveniente da applicazioni o aziende legittime, ma consentono di fornire il consenso a un'app dannosa.
  • Assicurarsi di riconoscere il nome dell'app e l'URL di dominio prima di fornire il consenso a un'applicazione.

Promuovere e consentire l'accesso alle app attendibili

  • Alzare di livello l'uso delle applicazioni verificate dall'editore. La verifica dell'autore consente agli amministratori e agli utenti finali di comprendere l'autenticità degli sviluppatori di applicazioni. Oltre 660 applicazioni di 390 editori vengono verificate finora.
  • Configurare i criteri di consenso delle applicazioni consentendo agli utenti di fornire il consenso solo a applicazioni specifiche considerate attendibili, ad esempio le applicazioni sviluppate dall'organizzazione o dagli editori verificati.
  • Informare l'organizzazione sul funzionamento delle autorizzazioni e del framework di consenso.
  • Comprendere i dati e le autorizzazioni richieste da un'applicazione e comprendere come funzionano le autorizzazioni e il consenso all'interno della piattaforma.
  • Assicurarsi che gli amministratori sappiano come gestire e valutare le richieste di consenso.

Controllare le app e le autorizzazioni concesse all'interno dell'organizzazione per assicurarsi che le applicazioni usate accedano solo ai dati necessari e siano conformi ai principi dei privilegi minimi.

Soluzioni di prevenzione

  • Informare il cliente e fornire consapevolezza e formazione sulla protezione delle concessioni di consenso delle applicazioni
  • Rafforzare il processo di concessione del consenso dell'applicazione con i criteri dell'organizzazione e i controlli tecnici
  • Configurare Crea pianificazione per esaminare le applicazioni con consenso
  • È possibile usare PowerShell per disabilitare le app sospette o dannose disabilitando l'app

Contenuto correlato

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