Ricerca in 5 minuti: individuazione delle app multi-tenant rischiose in Microsoft 365

Informazioni sulla caccia di 5 minuti: La caccia di 5 minuti è una nuova funzionalità disponibile nella Vectra AI nella scheda "Indaga". Ogni settimana troverai un breve frammento di ricerca all'interno del prodotto che evidenzia un comportamento specifico dell'aggressore e ti fornisce una query pronta all'uso per rilevarlo.

Perché le app multi-tenant ti mettono a rischio

Le applicazioni multi-tenant in Microsoft 365 sono progettate per l'accesso interorganizzativo, ma se configurate in modo errato possono creare una pericolosa backdoor. Una singola impostazione può esporre le risorse interne agli utenti esterni. Gli aggressori sfruttano questa vulnerabilità attraverso attacchi basati sul consenso, ottenendo un accesso non autorizzato senza rubare le credenziali. I ricercatori di sicurezza hanno recentemente dimostrato come questa precisa vulnerabilità abbia consentito l'accesso a più di 22 servizi interni di Microsoft. Per i team SOC, ciò significa che le app multi-tenant configurate in modo errato o abilitate involontariamente ampliano notevolmente la superficie di attacco.

Come gli hacker sfruttano le app multi-tenant

Gli avversari sfruttano queste debolezze in diversi modi:

1. Phishing scala
   Quando un'applicazione multi-tenant è esposta, gli aggressori possono indurre gli utenti a concedere il consenso OAuth. Una volta approvato, l'applicazione controllata dall'aggressore ottiene token legittimi per accedere alle risorse senza bisogno di rubare le credenziali.
2. Emissione di token da parte dell'autorità sbagliata
   Nei casi in cui un'app sia registrata in modo errato come multi-tenant, Entra ID potrebbe emettere token di accesso dal tenant dell'utente anziché dal tenant delle risorse. Ciò significa che l'autore dell'attacco viene autenticato, ma dall'autorità sbagliata, aggirando i controlli e ottenendo un accesso che l'applicazione non avrebbe mai concesso.
3. 
   di istanziazione dell'entità di servizio Accettando una richiesta di consenso si crea automaticamente un'entità di servizio per l'applicazione all'interno del tenant della vittima. Gli aggressori sfruttano questa vulnerabilità per mantenere l'accesso o ampliare l'ambito concatenando le autorizzazioni tra altre app.
4. Elenco delle app vulnerabili
   Eseguendo la scansione dei sottodomini e analizzando ID cliente parametri, gli aggressori possono identificare quali app sono configurate come multi-tenant. Ognuna di esse diventa un potenziale punto di accesso, soprattutto se gli sviluppatori hanno previsto un utilizzo single-tenant ma hanno lasciato abilitati gli endpoint comuni.
5. Passaggio ai sistemi interni
   Una volta ottenuto l'accesso, gli aggressori possono esplorare le applicazioni collegate, i portali interni o le API. Nel caso di studio di Microsoft, ciò ha comportato l'esposizione di hub di ingegneria, registri dei rischi e persino infrastrutture di compilazione, tutti accessibili da un account Microsoft 365 personale.

Il rischio non risiede in un singolo passo falso, ma nel modo in cui le impostazioni multi-tenant interagiscono con il consenso e l'emissione di token. Un'applicazione configurata in modo errato può aprire l'intero ambiente a utenti non autorizzati, fornendo agli aggressori un punto d'appoggio per esplorare dati sensibili o aumentare i privilegi.

Trasformare lo sfruttamento in rilevamento

Ora vediamo come individuare questi rischi nel proprio ambiente Entra ID. Le configurazioni errate non sempre lasciano tracce evidenti, ma ogni modifica in Entra ID lascia una traccia di audit. Concentrandosi su quando un'applicazione Disponibile ad altri inquilini la proprietà viene impostata su "true", è possibile identificare rapidamente i casi in cui un'app è stata resa multi-tenant, intenzionalmente o meno.

La seguente query è stata creata proprio per questo scopo. Cerca le modifiche recenti che abilitano l'accesso multi-tenant e fornisce il contesto necessario (chi ha apportato la modifica, da dove e quando) per decidere se l'azione è legittima o sospetta.

Obiettivo della query: rilevare se le applicazioni nel tenant sono state modificate per abilitare l'accesso multi-tenant e indagare sui dettagli della modifica:

SELECT timestamp, vectra.identity_principal, operation, extended_properties, object_id, device_properties, client_ip, modified_properties
FROM m365.active_directory._all WHERE any_match(modified_properties, m -> (m.display_name 
LIKE '%AvailableToOtherTenants%' AND m.new_value LIKE '%true%')) 
AND timestamp > date_add('day',-30, now())
ORDER BY timestamp DESC 
LIMIT 100

Cosa cercare nei risultati

Quando si esegue questa query, i risultati forniscono una chiara panoramica su come e quando le applicazioni vengono modificate per consentire l'accesso multi-tenant. Per distinguere le modifiche aziendali legittime dalle potenziali attività dannose, concentrare l'attenzione su queste aree:

1. Applicazioni modificate per l'accesso multi-tenant
   Controlla attentamente quali applicazioni sono state modificate per consentire l'accesso ad altri tenant. Le applicazioni business-critical raramente necessitano di questa impostazione, quindi le voci inaspettate dovrebbero destare sospetti.
2. L'identità o l'utente che ha apportato la modifica
   Il campo vectra.identity_principal mostra chi ha eseguito la modifica. Si trattava di uno sviluppatore, di un amministratore o di un account che normalmente non dovrebbe gestire le registrazioni delle app? Questo contesto può indicare rapidamente un errore interno o una compromissione esterna.
3. Indirizzi IP dei client delle richieste di modifica
   Confronta il client_ip con gli intervalli noti o i dati di geolocalizzazione. Indirizzi IP sconosciuti, località geografiche estere o fonti dannose note potrebbero indicare il coinvolgimento di un hacker nella modifica.
4. Modelli temporali delle modifiche
   Prestare attenzione al momento in cui sono avvenute le modifiche alla configurazione. Attività fuori orario, raffiche di modifiche multiple o raggruppamenti insoliti nei fine settimana e nei giorni festivi spesso corrispondono al comportamento degli aggressori. Combinando questi dati, è possibile distinguere le operazioni IT di routine dalle modifiche sospette che meritano un'indagine più approfondita.

Come approfondire le indagini

Se la query restituisce applicazioni che sono state rese multi-tenant, procedere come segue per determinare se la modifica è sicura, intenzionale o dannosa:

• Verificare se la configurazione multi-tenant era intenzionale e autorizzata
• Esamina le autorizzazioni e l'ambito dell'applicazione per valutare il potenziale impatto.
• Verificare se l'account utente modificante è stato compromesso
• Esamina l'IP del cliente per individuare anomalie geografiche o fonti dannose note.
• Convalidare la giustificazione commerciale dei requisiti di accesso multi-tenant
• Considerare la possibilità di disabilitare temporaneamente l'applicazione se la modifica sembra non autorizzata.

Considerazioni finali

Un'applicazione configurata in modo errato può consentire agli aggressori di ottenere un accesso che non dovrebbero mai avere. Eseguendo regolarmente questa ricerca, il team SOC può individuare rapidamente le modifiche non autorizzate e bloccare gli abusi basati sul consenso prima che si aggravino.

Se stai già utilizzando la Vectra AI , puoi esplorare questa e altre ricerche direttamente all'interno della piattaforma nella scheda Investigate, dove vengono pubblicate regolarmente nuove ricerche di 5 minuti per aiutarti a scoprire più rapidamente i comportamenti degli aggressori.

Non sei ancora cliente? Guarda la funzionalità 5-Minute Hunt in azione e scopri come la Vectra AI colma le lacune cloud dell'identità, della rete e cloud con la nostra demo autoguidata.