Il contesto: perché si parla di “enumerazione utenti” tramite OneDrive

A inizio novembre 2026 è tornata alla ribalta una tecnica di ricognizione contro i tenant Microsoft 365, nota da tempo nella comunità offensive security ma riportata di recente con dettagli aggiornati: è possibile scoprire quali User Principal Name (UPN) esistono davvero in un’organizzazione semplicemente interrogando gli URL personali di OneDrive, senza effettuare alcun tentativo di autenticazione. Microsoft, interpellata sul tema, ha classificato il comportamento come rischio basso: non è una violazione di per sé, ma una tecnica di raccolta informazioni che può alimentare attacchi successivi come phishing mirato, credential stuffing e password spraying. Per chi amministra un tenant Entra ID, capire come funziona questa tecnica è il primo passo per valutare realisticamente l’esposizione della propria organizzazione.

Come funziona la tecnica

1. Dall’UPN all’URL personale

Quando un utente di un tenant Microsoft 365 attiva un servizio come Word o Excel Online, OneDrive viene provisionato automaticamente e gli viene assegnato un sito personale con un URL derivato in modo prevedibile dal suo UPN. Nel passaggio da UPN a URL, punti e altri simboli vengono sostituiti con underscore, secondo questo schema:

https://<tenant>-my.sharepoint.com/personal/<UPN_trasformato>/_layouts/15/onedrive.aspx

# Esempio: se l'UPN è mario.rossi@contoso.com
# l'URL generato sarà del tipo:
https://contoso-my.sharepoint.com/personal/mario_rossi_contoso_com/_layouts/15/onedrive.aspx

La trasformazione è deterministica: conoscendo (o indovinando) uno schema di username aziendale e il nome del tenant, è possibile costruire a tavolino un URL candidato per ogni potenziale dipendente.

2. Scoprire il nome del tenant

Per costruire l’URL serve anche il nome del tenant Azure, che in molti casi non coincide ovviamente con il dominio pubblico dell’azienda. Questo valore può essere ricavato con tecniche di lookup già note nella comunità, rese popolari da strumenti come AADInternals e TREVORspray, che permettono di risalire al tenant a partire da un dominio verificato su Entra ID. Nei tenant con più domini configurati possono esistere più combinazioni valide da testare.

3. La differenza che tradisce: 401 contro 403

Il cuore della tecnica sta nella risposta HTTP a una semplice richiesta HEAD verso l’URL personale candidato. Gli account validi restituiscono un codice di stato diverso rispetto a quelli inesistenti: un 401 indica che SharePoint Online è configurato con Modern Authentication in modalità Block Access, mentre un 403 corrisponde alla configurazione predefinita Allow Access. In entrambi i casi, si tratta di un’impostazione a livello di SharePoint, non dell’intero tenant, e il punto fondamentale è che nessuna delle due risposte richiede un tentativo di autenticazione: la semplice forma della risposta HTTP basta a distinguere “l’utente esiste” da “l’utente non esiste”.

Chi ha documentato la tecnica nel dettaglio ha pubblicato anche uno strumento di automazione (uno script Python con registrazione dei risultati in SQLite e ricerca automatica del tenant), oltre a far riferimento a raccolte di wordlist di username plausibili per coprire gli schemi più comuni (nome.cognome, iniziale+cognome, e così via). È importante sapere che la tecnica funziona solo contro account effettivamente licenziati per OneDrive, quindi la copertura reale varia da organizzazione a organizzazione, e che, a differenza dei portali di login classici, qui non risultano applicati rate limit o blocchi automatici.

Perché Microsoft la considera “a basso rischio”

Dal punto di vista di Microsoft, scoprire che un UPN esiste non equivale a compromettere un account: non vengono rivelate password, non si aggira alcun controllo di autenticazione, e l’informazione esposta (l’esistenza di un indirizzo nel formato nome.cognome@azienda.com) è spesso già pubblica o facilmente deducibile da siti aziendali, LinkedIn o email. Per questo l’azienda non lo classifica come una vulnerabilità da correggere con una patch, ma consiglia di mitigarne l’impatto rafforzando le protezioni identitarie a valle, dove l’informazione raccolta verrebbe effettivamente sfruttata.

Chi ha analizzato la tecnica in dettaglio sottolinea anche un limite difensivo reale: non esistono, ad oggi, metodi noti e affidabili per rilevare questa enumerazione dal lato organizzazione, perché le richieste HTTP non lasciano tracce visibili nei log standard di sicurezza di Microsoft 365.

L’impatto pratico per un’azienda

Anche se non porta a un accesso diretto, conoscere con certezza quali UPN sono validi cambia significativamente l’efficacia degli attacchi successivi:

• Phishing mirato: le campagne possono concentrarsi solo su indirizzi confermati come reali, aumentando il tasso di successo e riducendo il rumore che potrebbe insospettire i team di sicurezza.
• Password spraying: provare poche password comuni contro una lista di account confermati validi è molto più efficiente (e più difficile da individuare) che tentarlo alla cieca su indirizzi inventati.
• Credential stuffing: le credenziali trapelate da altre violazioni possono essere testate selettivamente solo sugli UPN confermati, risparmiando tentativi e abbassando la probabilità di trigger su soglie di blocco.
• Social engineering: sapere con certezza che un indirizzo esiste rende più credibili pretesti di recupero password o richieste di supporto IT contraffatte.

Come proteggersi: mitigazioni concrete per i sistemisti

• Disattivare i siti OneDrive personali non necessari dall’amministrazione del tenant SharePoint/OneDrive per gli utenti che non ne hanno bisogno. Attenzione: gli utenti che hanno già attivato OneDrive mantengono l’URL personale anche dopo la disattivazione del servizio per nuovi utenti, quindi serve una pulizia mirata sugli account esistenti.
• Evitare di usare l’indirizzo email come username primario. L’indirizzo email è per natura un’informazione pubblica; l’username di accesso, quando possibile, non dovrebbe esserlo.
• Evitare schemi di username prevedibili. Formati come “nome.cognome” o numerazioni sequenziali sono enumerabili in poche ore. Alternative con suffissi numerici semi-casuali aumentano di ordini di grandezza lo sforzo richiesto per un’enumerazione completa, a patto di mantenere alias email leggibili per i contatti esterni.
• Non fermarsi a OneDrive. Anche Microsoft Graph e Microsoft Teams espongono, in determinate condizioni, informazioni sufficienti a confermare l’esistenza di un account: la disattivazione dei siti personali di OneDrive da sola non chiude il problema.
• Rafforzare le protezioni “a valle”: abilitare il Smart Lockout di Entra ID, imporre MFA resistente al phishing (chiavi di sicurezza o Windows Hello for Business) su tutti gli account, disattivare l’autenticazione legacy che non supporta MFA, e attivare Entra ID Protection per intercettare pattern di accesso anomali che spesso seguono una fase di enumerazione.
• Monitorare i log di sign-in Entra ID per individuare tentativi di accesso falliti distribuiti su molti account in un intervallo di tempo ristretto: è spesso il segnale che la fase di enumerazione è già stata seguita da un tentativo di sfruttamento.

Conclusione

La vicenda dell’enumerazione utenti via OneDrive è un buon promemoria di un principio spesso trascurato nella sicurezza dei tenant Microsoft 365: non tutte le informazioni che un attaccante può raccogliere senza autenticarsi vengono considerate vulnerabilità da Microsoft, ma questo non significa che siano innocue. Per chi amministra l’identità aziendale, la risposta corretta non è aspettare una patch che probabilmente non arriverà, ma ridurre la superficie di enumerazione dove possibile (username non prevedibili, siti personali disattivati per chi non ne ha bisogno) e, soprattutto, blindare i controlli che intervengono dopo che un attaccante ha già in mano una lista di account validi.

Fonti: 4sysops – Microsoft calls OneDrive username probing low risk, TrustedSec – OneDrive to Enum Them All.