Caccia in 5 minuti: Rilevare le applicazioni multi-tenant a rischio in Microsoft 365

Informazioni sulla caccia in 5 minuti: La caccia in 5 minuti è una nuova funzionalità disponibile nella piattaforma Vectra AI. Vectra AI Platform nella scheda Investigate. Ogni settimana, all'interno del prodotto, troverete un breve frammento di caccia che mette in evidenza un comportamento specifico dell'attaccante e vi fornisce una query pronta da eseguire per rilevarlo.

Perché le applicazioni multi-tenant vi mettono a rischio

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

Come gli aggressori sfruttano le applicazioni multi-tenant

Gli avversari sfruttano queste debolezze in diversi modi:

1. Consent Phishing at Scale
   Quando un'app multi-tenant è esposta, gli aggressori possono indurre gli utenti a concedere il consenso OAuth. Una volta approvato, l'app controllata dall'aggressore ottiene token legittimi per accedere alle risorse senza dover rubare le credenziali.
2. Emissione di token dall'autorità sbagliata
   Nei casi in cui un'applicazione è registrata in modo errato come multi-tenant, Entra ID può emettere token di accesso dal tenant dell'utente piuttosto che dal tenant della risorsa. Ciò significa che l'aggressore viene autenticato, ma dall'autorità sbagliata, aggirando i controlli ed ereditando l'accesso che l'applicazione non intendeva concedere.
3. Istanziazione del service principal
   L'accettazione di una richiesta di consenso crea automaticamente un service principal per l'applicazione all'interno del tenant della vittima. Gli aggressori sfruttano questo aspetto per persistere nell'accesso o per aumentare l'ambito di applicazione concatenando le autorizzazioni di altre applicazioni.
4. Enumerazione delle applicazioni vulnerabili
   Esaminando i sottodomini e analizzando i parametri client_id, gli aggressori possono identificare quali applicazioni sono configurate come multi-tenant. Ognuna di esse diventa un potenziale punto di ingresso, soprattutto se gli sviluppatori hanno ipotizzato 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 connesse, i portali interni o le API. Nel caso di studio di Microsoft, ciò ha portato all'esposizione di hub di progettazione, registri dei rischi e persino infrastrutture di costruzione, il tutto accessibile da un account personale Microsoft 365.

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 mal configurata può aprire l'intero ambiente a utenti non autorizzati, offrendo agli aggressori un punto d'appoggio per esplorare dati sensibili o aumentare i privilegi.

Trasformare lo sfruttamento in rilevamento

Ora cerchiamo di capire come individuare questi rischi nel vostro ambiente Entra ID. Le configurazioni errate non lasciano sempre tracce evidenti, ma ogni modifica in Entra ID lascia una traccia di audit. Concentrandosi sul momento in cui la proprietàAvailableToOtherTenants di un'applicazione viene impostata su "true", è possibile identificare rapidamente i casi in cui un'applicazione è stata resa multi-tenant, intenzionalmente o meno.

La seguente query è stata creata proprio per far emergere questo aspetto. Cerca le modifiche recenti che consentono l'accesso multi-tenant e fornisce il contesto necessario (chi ha effettuato 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 consentire l'accesso multi-tenant e analizzare i 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())
ORDINATO PER timestamp DESC 
LIMITE 100

Cosa cercare nei risultati

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

1. Applicazioni modificate per l'accesso multi-tenant
   Osservate attentamente quali applicazioni sono state modificate per consentire l'accesso ad altri tenant. Le applicazioni critiche per l'azienda raramente necessitano di questa impostazione, quindi le voci inaspettate dovrebbero far scattare un campanello d'allarme.
2. L'identità o l'utente che ha effettuato la modifica
   Il campo vectra.identity_principal mostra chi ha eseguito la modifica. Si tratta 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 client delle richieste di modifica
   Incrociare il client_ip con gli intervalli conosciuti o i dati di geolocalizzazione. IP sconosciuti, geografie estere o fonti dannose note potrebbero indicare la mano di un aggressore nella modifica.
4. Schemi temporali delle modifiche
   Prestate attenzione a quando avvengono le modifiche alla configurazione. Attività fuori orario, raffiche di modifiche multiple o raggruppamenti insoliti nei fine settimana e nei giorni festivi sono spesso in linea con il 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 vostra query fa emergere applicazioni che sono state rese multi-tenant, utilizzate i seguenti passaggi per determinare se la modifica è sicura, intenzionale o dannosa:

• Verificare se la configurazione multi-tenant è intenzionale e autorizzata .
• Esaminare le autorizzazioni e l'ambito dell' applicazione per valutare l'impatto potenziale.
• Controllare se l'account dell'utente che modifica è stato compromesso
• Esaminare l'IP del client per verificare la presenza di anomalie geografiche o di fonti dannose note.
• Convalidare la giustificazione aziendale per i requisiti di accesso multi-tenant
• Considerate la possibilità di disabilitare temporaneamente l'applicazione se la modifica appare non autorizzata.

Pensieri conclusivi

Un'applicazione mal configurata può dare agli aggressori un accesso che non dovrebbero mai avere. Eseguendo regolarmente questo hunt, il team SOC può far emergere rapidamente le modifiche non autorizzate e bloccare gli abusi basati sul consenso prima che si intensifichino.

Se state già utilizzando la Vectra AI Platform, potete esplorare questa e altre cacce proprio all'interno della piattaforma, nella scheda Investigate, dove vengono pubblicate regolarmente nuove cacce in 5 minuti per aiutarvi a scoprire più rapidamente i comportamenti degli aggressori.

Non siete ancora clienti? Guardate la funzionalità 5-Minute Hunt in azione e scoprite come la Vectra AI Platform colma le lacune di rilevamento di identità, rete e cloud con la nostra demo autoguidata.