La richiesta potrebbe arrivare mentre si sta sperimentando un nuovo assistente per il lavoro: seguire un collegamento, riconoscere una schermata Microsoft, approvare le autorizzazioni necessarie ad attivare il servizio.
È in questo passaggio, ormai familiare a chi collega applicazioni e piattaforme cloud, che si colloca BluePhishing, la nuova tecnica descritta dai ricercatori di Proofpoint.
Indice degli argomenti
BluePhishing: come funziona l’inganno
L’obiettivo dell’inganno è ottenere il consenso a un modello di agente controllato dall’attaccante, creando le condizioni per introdurre nuove identità nell’ambiente dell’organizzazione.
La fiducia accordata a un presunto strumento di produttività diventa così una risorsa operativa per chi attacca.
Occorre subito precisare il perimetro della scoperta: Proofpoint presenta BluePhishing come una ricerca proof-of-concept e dichiara di non avere identificato attività malevole in corso al momento della pubblicazione. Il lavoro documenta quindi un percorso di abuso e le sue implicazioni difensive, senza dimostrare che esista già una campagna contro le aziende.
È importante, quindi, distinguere una superficie di attacco emergente da un fenomeno già noto e sfruttato, sulla quale l’adozione delle tecnologie e la maturazione dei controlli stanno procedendo contemporaneamente.
I dettagli della tecnica BluePhishing
Il meccanismo appartiene alla famiglia del consent phishing, che sfrutta l’ingegneria sociale per indurre una persona ad approvare l’accesso di un’applicazione alle risorse disponibili.
Nell’esperienza dell’utente, il momento decisivo può svolgersi all’interno di un flusso di autorizzazione autentico. Per questo la verifica del dominio, pur rimanendo utile, non esaurisce il problema: bisogna capire quale soggetto stia ricevendo fiducia, per quali operazioni e con quale estensione. Una pagina legittima può presentare una richiesta di consenso per un’applicazione controllata da un soggetto ostile.
BluePhishing trasferisce questa logica al framework Microsoft Entra Agent Identity. Per seguirne il funzionamento servono tre concetti. Il blueprint è il modello che definisce configurazione e credenziali degli agenti; il blueprint principal ne rappresenta la presenza all’interno di uno specifico tenant, cioè l’ambiente dell’organizzazione; le agent identity sono le singole identità create a partire da quel modello.
Questa struttura permette di gestire più agenti collegati a una stessa origine, ma introduce anche relazioni di fiducia che la difesa deve riuscire a ricostruire.
Nello scenario descritto da Proofpoint, l’attaccante prepara un blueprint nel proprio tenant, configurandone credenziali e autorizzazioni, quindi induce una vittima ad accordargli il consenso.
Nell’ambiente destinatario viene creato un blueprint principal al quale è attribuito automaticamente il permesso AgentIdentity.CreateAsManager. Tale permesso consente di creare identità di agenti associate al modello. Il comunicato lo definisce irrevocabile: il riferimento riguarda il permesso attribuito a quel principal, e non va interpretato come l’affermazione che ogni conseguenza dell’attacco sia impossibile da contenere.
Da questa presenza iniziale possono derivare ulteriori identità e, nelle condizioni previste dai flussi di autenticazione e dalle autorizzazioni ottenute, token utilizzabili per operare sulle risorse accessibili. Il limite indicato dai ricercatori è di 250 identità associate a un blueprint. È un elemento rilevante per la gestione dell’incidente, perché una singola approvazione può generare una pluralità di oggetti da esaminare. Quel numero, tuttavia, non equivale a 250 account umani compromessi e non implica automaticamente il controllo completo del tenant.
L’impatto dipende infatti dalla natura dei permessi e da chi può approvarli. La ricerca tecnica distingue il consenso amministrativo da quello dell’utente: i permessi applicativi richiedono un’approvazione amministrativa, mentre quelli delegati operano nel contesto dell’utente e presentano ulteriori vincoli per il loro utilizzo. Le policy possono inoltre impedire il consenso diretto e richiedere un passaggio di approvazione.
La difficoltà difensiva riguarda anche la visibilità
Proofpoint richiama i limiti di esposizione dei permessi ereditati negli strumenti di amministrazione e nelle API, un aspetto che può rendere più complesso ricostruire le capacità effettive delle identità.
Nel dettaglio dei test, i ricercatori circoscrivono l’ereditarietà silenziosa osservata ai permessi delegati concessi attraverso il consenso utente.
Per chi svolge attività di audit, la conseguenza è la necessità di valutare le relazioni fra modello, autorizzazioni e agenti derivati, evitando di considerare ciascuna identità come un oggetto indipendente.
A questa complessità si aggiunge una questione di contesto. Un agente è progettato per svolgere attività con una certa autonomia: la sua operatività può quindi apparire coerente con le aspettative dell’organizzazione.
In un ambiente che ne utilizza molti, distinguere un’identità introdotta attraverso un consenso ingannevole richiede informazioni sulla sua provenienza, sul responsabile e sullo scopo autorizzato.
L’etichetta “AI” rischia, inoltre, di facilitare l’approvazione quando l’urgenza di sperimentare nuovi strumenti precede la comprensione dei loro privilegi.
Le misure di mitigazione
Le misure proposte da Proofpoint partono dalla governance del consenso: limitare l’approvazione di blueprint esterni, stabilire quali autorizzazioni possano essere accordate dagli utenti e applicare il principio del privilegio minimo.
A questi interventi si affiancano i controlli di Conditional Access per gli agenti e il monitoraggio degli eventi relativi a blueprint e identità nei log di audit.
Anche la formazione deve raggiungere il momento dell’autorizzazione: in sostanza bisogna imparare a porsi una domanda come “quali accessi si stanno concedendo e a chi?”, oltre alla verifica dell’attendibilità del messaggio ricevuto.
Partecipa alla community