Password Spraying in AD ed Entra ID: rilevamento

Che cos’è il Password Spraying?

Password spraying è una tecnica di brute force che testa una password, o un elenco molto ridotto di password comuni, contro molti account invece di provare molte password contro un singolo account. MITRE la classifica come T1110.003 sotto Brute Force.

Questo modello operativo conta perché è pensato per evitare gli effetti più evidenti del brute force classico. Invece di bloccare rapidamente un singolo account dopo molti tentativi falliti, l’attaccante distribuisce poche ipotesi su molte identità e aspetta di colpire quella più debole.

L’ambito di questo articolo è l’identità ibrida: Active Directory, Microsoft Entra ID e i percorsi cloud o di accesso remoto che accettano ancora autenticazione basata su password. Il password spraying non è solo un problema on-prem. Sia CISA sia Microsoft lo descrivono come uno schema frequente di accesso iniziale contro servizi di identità federati, cloud ed esposti a Internet.

Come funziona il Password Spraying

La definizione MITRE è il punto di partenza corretto: l’avversario usa una singola password, o un elenco molto piccolo di password comuni, contro molti account diversi per evitare i lockout che normalmente si verificherebbero se bruteforzasse ripetutamente un solo account.

In pratica, gli attaccanti costruiscono prima l’elenco di account target e solo dopo lo “spruzzano” con poche password candidate deboli.

Fonti tipiche degli account bersaglio:

nomi utente o indirizzi email esposti pubblicamente
convenzioni di naming ricavate da LinkedIn, siti aziendali o rubriche compromesse
Global Address List dopo la compromissione di un primo account cloud
identità ibride sincronizzate, presenti sia in AD sia in Microsoft Entra ID

Percorsi tipici colpiti:

endpoint di login Microsoft 365 / Entra
flussi di autenticazione federata
portali VPN
Outlook Web o altre interfacce mail esposte all’esterno
RDP o altri workflow di accesso remoto pubblicati
LDAP, Kerberos, SMB o altri protocolli interni una volta che l’attaccante è già dentro la rete

MITRE evidenzia anche una nuance importante lato detection: gli attaccanti possono preferire tentativi LDAP e Kerberos perché talvolta risultano meno visibili dei fallimenti SMB che più spesso generano l’evento 4625.

Perché il Password Spraying funziona ancora

Il password spraying è efficace perché sfrutta scala e prevedibilità, non soltanto una singola debolezza tecnica.

Le password deboli esistono ancora su larga scala

La documentazione Microsoft Entra Password Protection è esplicita: Microsoft blocca password deboli sulla base di telemetria reale di spray, proprio perché password deboli e loro varianti restano sufficientemente comuni da essere rilevanti dal punto di vista operativo.

Restano esposti percorsi password-only

L’allerta CISA sul brute force e i report più recenti di Microsoft sulle intrusioni cloud indicano la stessa debolezza: se il target espone ancora accesso single-factor basato su password, un solo successo può bastare per iniziare discovery, persistenza o movimento laterale.

I percorsi legacy e federati ampliano la superficie di attacco

CISA avverte esplicitamente che le campagne di password spraying prendono spesso di mira SSO e applicazioni cloud che usano autenticazione federata. Anche il reporting più recente di Microsoft mostra il password spray come primo passo prima di ricognizione più ampia del tenant Entra e tentativi di persistenza.

Il ritmo low-and-slow evita lockout rumorosi

L’obiettivo dello spraying non è la velocità contro un solo account. L’obiettivo è l’affidabilità su molti account senza superare troppo rapidamente le soglie di lockout per singola identità.

Prerequisiti per un attacco di Password Spraying riuscito

Il password spraying di solito ha successo quando si sovrappongono più problemi.

1. L’attaccante può enumerare nomi utente validi

Una campagna di spraying è molto più semplice quando i nomi utente seguono schemi prevedibili o sono facilmente ricavabili dall’esterno. Formati email pubblici, alias amministrativi prevedibili e nomi identici tra cloud e on-prem aiutano tutti l’attaccante.

2. L’autenticazione basata su password è ancora esposta

Se il tenant o l’ambiente continuano a esporre percorsi di valore protetti solo da password, l’attaccante ha qualcosa da colpire. Ciò include login cloud, VPN, accesso remoto, federation e alcune superfici interne di autenticazione.

3. La baseline delle password è abbastanza debole da far funzionare pochi candidati

Questo è esattamente il problema di controllo affrontato da Sicurezza delle Password in Active Directory: errori critici. Uno spray funziona perché una parte degli utenti continua a scegliere password deboli, prevedibili o legate all’organizzazione.

4. La copertura MFA è incompleta o aggirabile sul percorso target

Anche quando lo spray produce solo una password valida, l’account diventa molto meno utile se sul percorso corretto esistono MFA forte o controlli successivi resistenti al phishing. CISA elenca esplicitamente l’assenza di MFA tra le caratteristiche comuni degli ambienti vittima.

5. Il monitoraggio è troppo debole per ricostruire il pattern

Pochi tentativi falliti contro un solo account sono facili da ignorare. Il vero segnale è un grande numero di fallimenti su molti account dalla stessa fonte, dalla stessa famiglia di infrastruttura o con lo stesso pattern temporale. Senza questa correlazione, il password spraying è facile da perdere.

La catena di attacco

Una tipica catena di intrusione basata su password spraying assomiglia a questa.

Passo 1 - Costruire l’elenco degli account

L’attaccante raccoglie nomi utente da fonti pubbliche, vecchie violazioni, rubriche o mailbox già compromesse.

Passo 2 - Scegliere un piccolo elenco di password

Le password scelte sono spesso stagionali, legate all’azienda o comunque abbastanza comuni da rispettare i requisiti di complessità restando prevedibili.

Passo 3 - Spruzzare contro molti account

Anziché martellare una sola identità, l’attaccante prova poche password contro molti utenti e distribuisce i tentativi nel tempo per evitare soglie di lockout troppo evidenti.

Passo 4 - Usare il primo account riuscito per la ricognizione

Il reporting Microsoft su Peach Sandstorm rende chiaro il rischio reale: un solo account riuscito può essere sufficiente per tenant discovery, tentativi di persistenza o ulteriore ricognizione cloud.

Passo 5 - Espandere l’accesso

Da lì l’attaccante può:

raccogliere altri nomi utente e ruoli
scaricare mail o la Global Address List
prendere poi di mira utenti privilegiati
muoversi verso applicazioni, subscription o infrastrutture collegate all’identità compromessa

Per questo il password spraying non è solo un problema di login falliti. È un problema di accesso iniziale che diventa spesso un problema di privilegi e persistenza.

Password Spraying vs altre tecniche di brute force

Questi termini vengono spesso confusi, ma non indicano la stessa cosa.

Password spraying = una o poche password contro molti account
Password guessing = tentativi più diretti contro un singolo account
Credential stuffing = riuso di coppie username/password già note da altre violazioni
Brute force classico = molti tentativi contro una singola identità o un singolo segreto fino al successo

Questa distinzione conta operativamente perché strategie di detection e lockout cambiano in modo significativo.

Rilevamento

Non esiste un rilevatore universale unico per il password spraying, perché la tecnica attraversa superfici cloud, federate e on-prem. Il modello utile è di nuovo la correlazione.

Segnali centrati su cloud ed Entra

Per Microsoft Entra ID, i segnali più utili includono:

fallimenti ripetuti di sign-in contro molti utenti dalla stessa IP, dallo stesso cluster infrastrutturale o dallo stesso user agent
lo stesso pattern di password candidata testato su molti account nel tempo
comportamento ripetuto di Smart Lockout o blocco sign-in su molti account dalla stessa fonte
attività di rischio medio o alto associata a password failures ripetuti o a infrastruttura sospetta
uso di autenticazione legacy su percorsi di identità esposti a Internet

La documentazione Microsoft su Smart Lockout aggiunge alcuni fatti importanti:

Smart Lockout è attivo di default per i tenant Microsoft Entra
la soglia predefinita è 10 tentativi falliti per Azure Public e 3 per Azure US Government
la durata iniziale del lockout parte da 60 secondi e aumenta dopo errori ripetuti
Smart Lockout traccia gli ultimi tre hash di password errate, così la ripetizione della stessa password errata non continua a incrementare il contatore
questo tracciamento per hash non è disponibile negli scenari di pass-through authentication, perché l’autenticazione avviene on-premises

Questi dettagli contano, perché molti team sopravvalutano ciò che il lockout, da solo, può fare in un ambiente ibrido.

Segnali AD e on-prem

Per il monitoraggio Windows on-prem, i segnali utili includono:

picchi di errori 4625 dalla stessa fonte contro molti account quando sono coinvolti SMB o percorsi simili
errori di preautenticazione Kerberos 4771 su molti utenti in una finestra breve
errori LDAP o Kerberos che si allineano a un pattern multi-account anche quando non sembrano una classica sequenza SMB
la stessa fonte o lo stesso percorso di relay che tocca molte identità con una cadenza bassa ma persistente

MITRE avverte esplicitamente che i tentativi LDAP e Kerberos possono essere meno propensi a generare i pattern di failure Windows più visibili su cui spesso i difensori fanno affidamento. Ecco perché Monitoraggio Sicurezza AD: Event ID e SIEM è direttamente pertinente qui.

Come appare una buona correlazione

Una detection efficace del password spraying è di solito formulata così:

una IP, un ASN, uno user agent o un piccolo set di infrastrutture
molti username target
pochissimi tentativi per account
un pattern ripetuto di password candidata o di timing
uno o due account riusciti seguiti da discovery o attività orientata ai privilegi

Perché Smart Lockout e i log non bastano da soli

Smart Lockout riduce il rischio, ma Microsoft chiarisce che non garantisce che un utente legittimo non verrà mai bloccato e non sostituisce autenticazione più forte o password policy migliore. Una buona detection dipende ancora da review dei log, alerting e conoscenza precisa dei percorsi esposti.

Remediation

La mitigazione del password spraying non è solo un esercizio di password policy. È la combinazione di password più forti, meno percorsi password-only esposti, controlli post-password più forti e una migliore protezione dei bordi di autenticazione ibrida.

1. Imporre MFA forte sui percorsi di identità esposti

CISA e Microsoft raccomandano entrambe la MFA come mitigazione centrale. Per i sistemi di identità esposti pubblicamente, in particolare Microsoft 365, portali amministrativi, VPN e accesso remoto, una password ottenuta via spray non dovrebbe bastare per proseguire.

È anche per questo che Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta e Accesso Condizionale Azure: bypass MFA e auth legacy sono direttamente vicini a questo tema. La MFA deve essere presente sui percorsi giusti e applicata correttamente.

2. Usare Smart Lockout correttamente in Entra

Microsoft documenta Smart Lockout come protezione di default contro brute force e password spraying, ma i team ibridi devono configurarlo con criterio:

mantenere la soglia di Microsoft Entra più bassa della soglia on-prem AD DS
mantenere la durata del lockout Entra più lunga di quella di AD DS
capire che la pass-through authentication cambia parte del comportamento di Smart Lockout
verificare che la policy di account lockout on-prem non stia creando soprattutto problemi di disponibilità senza ridurre davvero il rischio di spray

3. Distribuire Microsoft Entra Password Protection

Microsoft Entra Password Protection è uno dei controlli anti-spray più chiari disponibili, perché è costruito su telemetria reale di spray e blocca password deboli note e loro varianti.

Punti di implementazione importanti dalla documentazione Microsoft:

i tenant cloud ricevono di default la global banned password list
è possibile aggiungere password vietate personalizzate per termini deboli specifici del tenant
AD DS on-prem può usare la stessa famiglia di controlli tramite gli agent Microsoft Entra Password Protection
Microsoft raccomanda di iniziare un deployment on-prem in modalità Audit prima di passare a Enforced

Questo conta molto negli ambienti ibridi, dove all’attaccante interessa colpire sia le password on-prem sia quelle cloud, purché rimangano deboli.

4. Ridurre autenticazione legacy e superfici password-only esposte

L’autenticazione legacy resta interessante per gli attaccanti perché conserva vecchi percorsi di accesso basati su password e può aggirare parte dei controlli più forti presenti nei flussi moderni. Se resta abilitata, i difensori lasciano ancora percorsi meno costosi da tentare.

Questo è direttamente collegato a Azure Tenant Hardening: Security Defaults e, più in generale, alla review del Conditional Access.

5. Proteggere le identità privilegiate in modo diverso dal resto della popolazione

Un successo su un utente di basso valore è già negativo. Un successo su un account privilegiato è spesso il vero incidente. Questo significa:

requisiti MFA più forti per i ruoli privilegiati
restrizioni di sign-in più strette per le identità amministrative
review attiva di utenti privilegiati obsoleti e account di emergenza
reset rapido e indagine immediata ogni volta che un account privilegiato viene preso di mira o bloccato

Qui Azure Identity Protection: Criteri di Rischio e Account Obsoleti e Sovraprivilegiati in AD entrano nella stessa storia di mitigazione.

6. Trattare un account riuscito come compromesso, non solo come password debole

Il threat reporting Microsoft è utile anche qui: una volta che lo spray ha successo, l’attore spesso passa rapidamente a ricognizione, persistenza e movimento laterale. Bisogna quindi resettare la password, ma anche revocare le sessioni, rivedere cambiamenti MFA, ispezionare l’attività successiva e verificare se l’account compromesso ha esposto altri dati o percorsi target.

Validazione dopo l’hardening

Non chiudere la remediation del password spraying solo perché Smart Lockout è attivo o perché è stata annunciata una nuova password policy. È necessario validare direttamente i percorsi esposti.

verificare quali percorsi esposti su Internet accettano ancora autenticazione password-only
confermare che la MFA sia applicata su quei percorsi, soprattutto per admin e account ad alto valore
testare il comportamento di Smart Lockout e confrontarlo con le impostazioni di lockout on-prem AD negli ambienti ibridi
rivedere i log di sign-in cercando pattern ampi di failure su molti utenti, non solo lockout singoli
confermare che Microsoft Entra Password Protection sia attivo nel cloud e, dove previsto, on-prem
verificare che termini deboli specifici del tenant, come nome azienda, nome prodotto o pattern stagionali, siano coperti nella custom banned list

Il vero criterio di successo è semplice: un piccolo elenco di password comuni non deve più produrre un foothold utile, né nel cloud né on-prem.

Come EtcSec rileva esposizione correlata

EtcSec non ha bisogno di una tassonomia artificiale password spraying per essere utile qui. Il valore sta nei controlli circostanti che determinano se uno spray ha successo o fallisce.

I finding più vicini sono quelli che rendono una campagna di spray praticabile fin dall’inizio: password policy debole lato AD e assenza di requisiti MFA sui percorsi di sign-in Entra esposti. Non sono la tecnica in sé, ma sono esattamente le lacune di controllo che trasformano uno spray ampio in un punto d’appoggio utile.

I controlli correlati più rilevanti sono:

Insieme, questi controlli indicano se l’ambiente continua a presentare una superficie facile per campagne di spraying.

Controlli correlati

Il password spraying va valutato insieme a igiene delle password, enforcement MFA, Smart Lockout, risposta al rischio identitario e monitoraggio. Se vuoi ridurre il successo reale delle campagne di spray e non solo i fallimenti rumorosi, esamina questo tema insieme a Sicurezza delle Password in Active Directory: errori critici, Sicurezza delle Identita Azure: Perche l'MFA da Solo Non Basta, Azure Identity Protection: Criteri di Rischio, Accesso Condizionale Azure: bypass MFA e auth legacy, Come auditare la sicurezza di Microsoft Entra ID (Azure AD): guida pratica e Azure Tenant Hardening: Security Defaults.