Un'interfaccia di monitoraggio esposta senza autenticazione su un'applicazione Java, credenziali sensibili salvate in chiaro in un foglio di calcolo e un flusso OAuth2 che il sistema MFA non riesce a intercettare. Tre debolezze distinte, nessuna delle quali richiede exploit sofisticati o malware, che combinate hanno permesso a un attaccante di compromettere un account di servizio SharePoint ed esfiltrare dati da SharePoint Online. Il caso è documentato da Trend Micro in un report che ricostruisce la kill chain e mette in luce il pattern di attacco sempre più comune di autenticarsi con credenziali valide e operare come un utente legittimo.

La catena di attacco parte con Spring Boot, un framework Java per la costruzione rapida di applicazioni e microservizi. Spring Boot Actuator è il modulo integrato che espone informazioni operative sull'applicazione in esecuzione, progettato per il monitoraggio interno; quando viene reso pubblicamente accessibile senza autenticazione diventa una finestra aperta sulla configurazione dell'applicazione.

Nell'incidente esaminato da Trend Micro, le interfacce di Spring Boot Actuator erano accessibili senza autenticazione. Una di esse ha rivelato un blocco di configurazione relativo all'integrazione con SharePoint, che includeva il nome utente dell'account di servizio SharePoint, l'URL dell'host, il nome del sito e il fatto che le credenziali provenissero da un file application.yml. La password era mascherata, ma questo era irrilevante dato che l'attaccante aveva appreso che esisteva un account valido, in cui erano conservate le credenziali e a quale sistema di integrazione corrispondevano. Era ricognizione di alta qualità, ottenuta semplicemente interrogando un'interfaccia pubblica.

Nel corso dell’indagine, i ricercatori di Trend Micro hanno scoperto anche che i secret dell'applicazione Azure AD interna erano conservati in chiaro in un foglio di calcolo. Il file conteneva client-id, client-secret e secret-id, ossia le credenziali che l'applicazione utilizzava per fare richiesta di token ad Azure AD. Dal punto di vista funzionale, un client secret funziona come una password: chiunque disponga del client ID e del client secret può autenticarsi e richiedere token ad Azure AD.

La conservazione di queste credenziali in un foglio di calcolo è un problema operativo frequente, nato dalla comodità di documentare informalmente le credenziali di test o di sviluppo. Tuttavia, all’atto pratico le credenziali diventano facilmente copiabili, bypassando qualsiasi sistema centralizzato di gestione dei secret e risultano accessibili a chiunque abbia accesso al file. Nel caso specifico, l'attaccante ha ottenuto il client secret e lo ha combinato con le informazioni ricavate dall'interfaccia Actuator per costruire una richiesta di autenticazione completa.

Veniamo al terzo anello della catena, ROPC (Resource Owner Password Credentials), un flusso OAuth2 che consente a un'applicazione di autenticarsi trasmettendo direttamente username e password all'identity provider, senza reindirizzare l'utente a una pagina di login. Il problema è che ROPC è strutturalmente incompatibile con i controlli di autenticazione moderni: l'MFA presuppone che ci sia un utente in grado di rispondere a una verifica, un codice OTP, una notifica push, una chiave hardware. ROPC è completamente programmatico, l'autenticazione avviene in modo silenzioso tramite richieste API e l'utente potrebbe non accorgersi mai che il proprio account è stato utilizzato.

In pratica, Azure AD riceve una richiesta con client-id, client-secret, username e password, valida le credenziali e restituisce un access token, senza che l'MFA venga mai attivato. Se l'attaccante dispone delle credenziali, il gioco è fatto. Ed è esattamente quello che è successo nel caso documentato da Trend Micro, in cui i primi due tentativi di autenticazione sono falliti perché mancava il client_secret corretto. I log mostrano tentativi quasi simultanei su applicazioni diverse del tenant, con timestamp ravvicinati che indicano automazione delle richieste. Quando l'attaccante ha fornito il client_secret recuperato dal foglio di calcolo, l'autenticazione è riuscita e Azure AD ha rilasciato un access token Microsoft Graph valido.

Con il token in mano, l'attaccante ha avuto accesso alle risorse SharePoint tramite Microsoft Graph. I log mostrano accesso ai siti SharePoint, enumerazione delle document library e download di file. Nessun malware, nessun exploit: solo credenziali valide e accesso API legittimo. Questa è la caratteristica più rilevante del caso dal punto di vista difensivo. I sistemi di detection tradizionali, calibrati per individuare comportamenti anomali o codice malevolo, non hanno elementi evidenti su cui agire quando l'attaccante si muove come un utente autorizzato.

Come chiudere le falle

A conclusione dell’indagine, Trend Micro sottolinea la lezione da apprendere: le strategie difensive devono focalizzarsi sulla limitazione di ciò che un attaccante può fare una volta autenticato, non solo verso l'impedire l'autenticazione stessa. In particolare, il report individua tre aree di intervento. La prima riguarda Spring Boot Actuator: le interfacce di monitoraggio interno, in particolare /env e /configprops, non devono mai essere pubblicamente accessibili in produzione. La protezione può avvenire tramite IP allowlist, reverse proxy con autenticazione obbligatoria o disabilitazione delle interfacce non necessarie.

La seconda riguarda la gestione dei secret: credenziali, client secret e chiavi API non devono mai essere conservati in fogli di calcolo, documenti condivisi o file di configurazione non protetti. Qualsiasi credenziale esposta va ruotata immediatamente. L'adozione di sistemi centralizzati di gestione dei secret, come Azure Key Vault, elimina alla radice la pratica di documentare informalmente le credenziali.

La terza, e forse la più urgente per chi gestisce ambienti Microsoft 365 e Azure AD, riguarda ROPC: il flusso va disabilitato se non è strettamente necessario. In sua vece, le organizzazioni dovrebbero adottare flussi di autenticazione moderni che supportano l'MFA e le Conditional Access policy di Azure AD. La presenza di ROPC abilitato in un tenant trasforma ogni credenziale rubata in un bypass dell'MFA, rendendo di fatto inutile uno dei controlli di sicurezza più diffusi.