Rilevamento di Raffiche di Accessi Falliti su Entra ID: Perché Identity Protection Non le Rileva

Rilevamento di Raffiche di Accessi Falliti su Entra ID: Cos'È

Il rilevamento di raffiche di accessi falliti su Entra ID è una copertura volutamente limitata: Microsoft Entra ID Identity Protection non include alcun rilevamento di rischio nativo pensato per intercettare una raffica di accessi falliti contro un singolo account, anche se il segnale grezzo — decine di tentativi con password errata contro un account in una finestra di tempo breve — è direttamente presente nei log di accesso. Questo articolo spiega perché i rilevamenti nativi di Identity Protection non scattano su una pura sequenza di fallimenti, e come colmare il divario con una query KQL, una regolazione di Smart Lockout, e un avviso che notifichi prima del decimo tentativo, non dopo il primo riuscito.

Una password errata contro Entra ID finisce in SigninLogs con il codice di errore AADSTS50126, e la documentazione ufficiale di Microsoft per quel codice è chiara sul perché una singola occorrenza non significhi nulla: InvalidUserNameOrPassword — «Errore nella convalida delle credenziali dovuto a nome utente o password non validi. L'utente non ha inserito le credenziali corrette. È normale vedere un certo numero di questi errori nei log a causa di errori degli utenti.» Non è l'unico codice di fallimento delle credenziali documentato da Microsoft — AADSTS50056 è «Password non valida o nulla: la password non esiste nella directory per questo utente» — e un rilevamento che ne monitora solo uno vede solo parte della raffica. Un errore di battitura è rumore. Venti di questi contro lo stesso account in cinque minuti, o la stessa password provata contro cinquanta account in cinque minuti, non lo sono: nel primo caso è brute force mirato, nel secondo è password spraying, ed entrambi gli schemi si manifestano come lo stesso segnale grezzo: una raffica di 50126.

Questa distinzione conta per capire a cosa rimanda questo articolo. Se cerchi il manuale operativo dell'attaccante — enumerazione dei bersagli, liste di password comuni, perché lo spraying evita i blocchi per singolo account — è Password Spraying: Rilevamento e Prevenzione per Active Directory ed Entra ID. Questo articolo è l'altra metà: l'ingegneria di rilevamento sulla telemetria grezza che deve esistere perché il motore di rischio di Identity Protection lascia questo segnale specifico senza segnalazione.

Perché Identity Protection Non Lo Segnala

Microsoft documenta ogni rilevamento di rischio di accesso e utente offerto da Identity Protection, e nessuno di essi è «accessi falliti ripetuti contro un singolo account». I candidati più vicini mancano tutti questo segnale per una ragione specifica e documentata:

Il risultato pratico: una campagna di brute force mirata o un'ondata di spraying senza successo può svolgersi interamente all'interno di SigninLogs — visibile, con timestamp, attribuibile a un IP e a un insieme di account — senza mai toccare RiskState, RiskLevelAggregated, o una sola riga nel report degli utenti a rischio. Se il tuo monitoraggio si ferma alla dashboard di Identity Protection, questo schema è invisibile finché non ha successo.

Rilevamento: Costruisci Tu Stesso la Query

Poiché non esiste alcun riskEventType per questo schema, il rilevamento deve essere costruito direttamente contro SigninLogs, la tabella di Log Analytics in cui confluiscono gli eventi di accesso di Entra ID una volta abilitata l'esportazione diagnostica. Le colonne che contano:

Prima di scegliere una soglia, stabilisci la baseline del tuo tenant. Le query di esempio per SigninLogs pubblicate da Microsoft includono un punto di partenza per questo — «Failed Signin reasons» — adattato qui per isolare i codici di fallimento delle credenziali che contano:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50126", "50056", "50053")
| summarize Count = count() by ResultType, ResultDescription
| order by Count desc

Eseguila per prima. Se il normale rumore di 50126 dovuto a errori di battitura è già nell'ordine delle centinaia al giorno, una soglia di raffica a una sola cifra genererà avvisi per nulla. Con una baseline in mano, due query coprono le due varianti dello stesso divario del catalogo — brute force mirato contro un'identità, e spraying lento e discreto su molte:

Raffica contro un singolo account:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            SourceIPs = dcount(IPAddress),
            LastFailure = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailureCount >= 10
| order by FailureCount desc

Raffica distribuita su molti account da un'unica fonte:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            TargetedAccounts = dcount(UserPrincipalName),
            Accounts = make_set(UserPrincipalName, 20)
    by IPAddress, bin(TimeGenerated, 15m)
| where FailureCount >= 10 or TargetedAccounts >= 5
| order by FailureCount desc

Entrambe le query usano solo colonne documentate di SigninLogs; le soglie 10 e 5 sono punti di partenza illustrativi, non valori predefiniti Microsoft — dimensionale sulla baseline sopra, poi restringile man mano che i falsi positivi diminuiscono. Collega una delle due query a una regola analitica pianificata di Microsoft Sentinel (o a un avviso di log di Azure Monitor comune se non usi Sentinel) in modo che una raffica sollevi un incidente invece di attendere di essere scoperta durante una revisione manuale dei log.

Remediation / Rimedio

1. Restringi Smart Lockout invece di presumere che il valore predefinito basti

Smart Lockout è attivo per ogni tenant, ma i suoi valori predefiniti sono calibrati per l'usabilità generale, non per il rilevamento:

• La soglia di blocco predefinita è di 10 tentativi falliti (tenant Azure Public; 3 per Azure US Government), dopo di che l'account si blocca per 60 secondi iniziali, aumentando con blocchi ripetuti.
• Smart Lockout «usa la posizione familiare rispetto a quella non familiare per distinguere un attore malintenzionato dall'utente genuino», e «sia le posizioni familiari sia quelle non familiari hanno contatori di blocco separati» — quindi un attaccante che accede da una posizione mai usata dall'utente reale consuma un proprio contatore, tracciato indipendentemente dagli errori dell'utente stesso.
• Smart Lockout «tiene traccia degli ultimi tre hash di password errati per evitare di incrementare il contatore di blocco per la stessa password». Uno spraying che ripete la stessa password comune contro un account quindi non lo avvicina mai al blocco — che è esattamente il caso che la tua query deve intercettare. Microsoft nota che questo tracciamento degli hash «non è disponibile per i clienti con l'autenticazione pass-through abilitata».
• Personalizzare la soglia e la durata al di sotto del valore predefinito richiede Microsoft Entra ID P1 o superiore, configurabile in Entra ID > Metodi di autenticazione > Protezione password.

Una soglia più bassa scambia un po' di attrito per l'utente con l'arresto di una campagna di brute force ben prima che si chiuda la tua finestra di rilevamento di 15 minuti. Coordina la modifica con qualsiasi policy di blocco AD DS ibrida. Per l'autenticazione pass-through, Microsoft è esplicita: la soglia di blocco Entra «deve essere inferiore alla soglia di blocco account AD DS», impostata «in modo che la soglia di blocco account AD DS sia almeno due o tre volte superiore alla soglia di blocco Microsoft Entra» — il blocco cloud assorbe così l'attacco prima che raggiunga l'infrastruttura on-premise.

2. Trasforma la query KQL in un avviso permanente

Una query che gira solo quando qualcuno si ricorda di incollarla in Log Analytics non è un rilevamento. Salvala come regola analitica pianificata di Microsoft Sentinel (o un avviso di log di Azure Monitor) con una cadenza di 15 minuti che corrisponda alla finestra bin(), e indirizzala a chi gestisce gli incidenti di identità. Questo è il controllo che colma davvero il divario del catalogo — Identity Protection resta silenzioso su una pura raffica di fallimenti, quindi nient'altro ti avviserà.

3. Affianca una policy di Accesso Condizionale basata sul rischio di accesso per i casi che vanno a buon fine

Nulla di tutto questo sostituisce l'Accesso Condizionale basato sul rischio — lo completa. Se una raffica finisce per produrre un tentativo riuscito, una policy di rischio di accesso è ciò che impedisce a quella sessione di fare qualsiasi cosa. La guida completa per costruirne una è in Azure Identity Protection: Blocco delle Credenziali Trapelate; se la tua base di Accesso Condizionale ha altre lacune oltre al rischio di accesso, verificala con Lacune nell'Accesso Condizionale di Azure.

4. Attiva l'esportazione dei log di accesso prima di averne bisogno

SigninLogs si riempie solo una volta abilitata l'esportazione diagnostica verso Log Analytics — come qualsiasi flusso di Azure Monitor, cattura gli eventi in avanti, non retroattivamente. Attiva questa esportazione in Entra ID > Monitoraggio e integrità > Impostazioni di diagnostica ora, così la cronologia sarà disponibile la prossima volta che dovrai eseguire queste query contro un incidente già vecchio di una settimana.

Come EtcSec Rileva Questo

I controlli Risk Protection di EtcSec includono esattamente questa correlazione di telemetria grezza — tracciata internamente come RISK_FAILED_SIGNIN_BURST, classificata critica e mappata su MITRE ATT&CK T1110.003 — perché il motore di rischio di Identity Protection stesso, come documentato sopra, non ha alcun rilevamento legato al volume di fallimenti contro un singolo account. Il controllo esegue le stesse due forme delle query sopra, su una finestra fissa di 10 minuti: più di 50 fallimenti delle credenziali contro un utente, o più di 50 da un IP su più di 10 utenti distinti. Sono soglie di audit, impostate abbastanza alte perché un riscontro sia un incidente e non un punto di partenza — motivo per cui il KQL sopra parte più basso e chiede di stabilire prima una baseline. Si affianca ai controlli che verificano cosa succede una volta che Identity Protection effettivamente solleva un segnale: RISK_SIGNINS_NOT_INVESTIGATED (accessi a rischio senza follow-up) e RISK_NO_AUTOMATED_RESPONSE (rischio visibile, nessuna risposta automatizzata configurata), e alimenta direttamente il fatto che CA_NO_RISK_BASED_SIGNIN (nessuna policy di Accesso Condizionale basata sul rischio di accesso) conti nel tuo ambiente.

Per i rilevatori gemelli della stessa famiglia di telemetria grezza, vedi Rilevamento Anomalie di Accesso Service Principal Entra , Entra ID AiTM Token Replay, Rilevamento Viaggi Impossibili e MFA Fatigue: Rilevamento e Prevenzione in Microsoft Entra ID. Per il divario sul lato risposta una volta che Identity Protection si attiva davvero, vedi Entra ID Risk Protection: Credenziali Trapelate, Utenti a Rischio Non Risolti.

Riferimenti Principali

• Microsoft Learn: What are risk detections? (Entra ID Protection)
• Microsoft Learn: Prevent attacks using Smart Lockout (Microsoft Entra ID)
• Microsoft Learn: Microsoft Entra authentication & authorization error codes
• Microsoft Learn: Azure Monitor Logs reference — SigninLogs
• Microsoft Learn: Example log table queries for SigninLogs
• Microsoft Learn: Learn about the monitoring and health activity log schemas (Microsoft Entra ID)