Rilevare i tentativi di accesso dannosi non è facile
Recentemente abbiamo indagato su alcuni comportamenti sospetti in un ambiente in cui era stata configurata l'autenticazione senza password di Azure. Le indagini sono state avviate dopo che diversi utenti hanno ricevuto richieste inaspettate dall'app Authenticator. Fortunatamente, nessuno degli utenti è caduto nella trappola o ha permesso all'autore dell'attacco di accedere al proprio account.
Questo tipo di evento, noto come MFA Fatigue, è una pratica comune e prevedibile nelle organizzazioni di grandi e piccole dimensioni. Gli aggressori sfruttano questa tecnica di ingegneria sociale per indurre gli utenti ad accettare le richieste di autenticazione push, avendo già ottenuto risultati positivi in attacchi recenti, tra cui quello a Uber.
Lo scenario si è rivelato particolarmente difficile da indagare a causa dei registri associati alle richieste senza password non riuscite.
Le limitazioni nelle capacità di registrazione complicano le indagini
Il monitoraggio dei tentativi di accesso dannosi è fondamentale per proteggere cloud ed è possibile solo monitorando cloud disponibili. Sebbene Microsoft e altri cloud pubblichino schemi di log e forniscano accordi sul livello di servizio (SLA) per la consegna dei record, esistono ancora diversi problemi che affliggono cloud :
- I tipi di eventi registrati spesso non sono ben documentati e talvolta non sono documentati affatto.
- Alcuni dei valori e degli ID registrati sono interni al cloud e il loro significato non è chiaro.
- Nuovi tipi di registrazioni vengono aggiunti, tipi di registrazioni vengono ritirati e i formati delle registrazioni vengono modificati senza preavviso ai consumatori.
Tutto ciò complica il monitoraggio e la risposta agli incidenti e lascia cloud incerti sulla completezza dei registri e costretti a rincorrere cambiamenti non annunciati; diventa quindi difficile indagare sui prompt senza password non riusciti dai dati registrati.
Uno sguardo più approfondito alla scoperta e alla mitigazione degli errori di accesso senza password in Azure
Autenticazione senza password
Per chi non lo sapesse, l'autenticazione senza password è un'opzione affidabile per mitigare il rischio che gli utenti creino password non sicure. Esistono diversi modi per abilitare l'autenticazione senza password in Azure. Nell'ambiente esaminato è stata utilizzata l'app Microsoft Authenticator.
Per registrarsi all'autenticazione senza password, gli utenti finali devono seguire questi passaggi di configurazione dettagliati. Una volta registrati a questo metodo, gli utenti possono inserire il proprio nome utente nella finestra di accesso di Azure e quindi selezionare l'opzione "Usa un'app":
All'utente viene quindi fornito un numero da inserire nell'app mobile per completare il processo:
Se il numero corrisponde, l'utente viene autenticato. Pur essendo ragionevolmente sicuro, questo metodo non richiede più agli utenti di creare e ricordare password complesse, migliorando notevolmente l'usabilità.
Indagine
In passato abbiamo monitorato diversi modi di configurare l'autenticazione a più fattori (MFA) in Azure, incluso l'uso dell'accesso senza password con Microsoft Authenticator come secondo fattore (ovvero quando all'utente viene richiesto di inserire il codice nell'app dopo aver immesso la password corretta). Quando Microsoft Authenticator viene utilizzato come secondo fattore, nei log viene visualizzato uno dei due errori seguenti se le richieste di Authenticator vengono ignorate o il codice non è corretto:
- 50074 È richiesta un'autenticazione forte.
- 500121 Autenticazione non riuscita durante la richiesta di autenticazione avanzata.
Di conseguenza, le nostre query di rilevamento e ricerca sono state impostate per cercare questi codici di errore.
Tuttavia, quando l'app Microsoft Authenticator è configurata come unico fattore, come nel caso dell'autenticazione senza password, abbiamo riscontrato il seguente errore quando la richiesta è stata abbandonata
- {"errorCode":1003033,"failureReason":"The remote NGC session was denied."}
Questo codice di errore era nuovo, qualcosa che non avevamo mai visto prima e cercando su Internet non si trovano praticamente informazioni sulla sua origine. Anche il messaggio di errore era criptico, senza alcuna spiegazione sul significato di "NGC". Dopo alcune ricerche, abbiamo stabilito che corrisponde al GUID D6886603-9D2F-4EB2-B667-1971041FA96B, documentato come "PIN Credential Provider".
Esaminando il registro, abbiamo riscontrato altre incongruenze (vedi screenshot qui sotto):
- La posizione e i dettagli del dispositivo (in rosso) non sono stati inseriti.
- Mancano le informazioni relative all'app e alle risorse (in blu).
- Le informazioni sull'utente (in viola) sono limitate. UserPrincipalName e UserDisplayName non contengono i valori previsti (indirizzo e-mail e nome completo dell'utente). Invece, il valore UserId è presente in tutti e tre i campi.
Il codice di errore insolito e i dati mancanti nei registri rendono difficile segnalare tali eventi e indagare su di essi in modo adeguato.
Mitigazione
Data la difficoltà che abbiamo avuto nell'indagare su questo incidente, abbiamo voluto condividere i dettagli raccolti con la comunità della sicurezza, in modo che i professionisti del settore potessero adeguare le loro query di ricerca per individuare questa condizione. Noi di Vectra abbiamo già aggiornato i nostri prodotti per coprire questo scenario.
La query di ricerca potrebbe essere semplice come il seguente frammento di codice Kusto, che individuerà tutti i tentativi di accesso senza password non riusciti negli ultimi 30 giorni:
SigninLogs | dove TimeGenerated > ago(30d) | dove ResultType == 1003033
Potrebbero essere interessanti anche altri codici di errore relativi a NGC:
Conclusioni:
- Quando introduci nuovi metodi di autenticazione nel tuo ambiente, valuta i log risultanti dalle interazioni con questi nuovi meccanismi. Cerca nuovi codici di errore e tipi di record di log che potrebbero dover essere presi in considerazione per il monitoraggio e gli avvisi.
- Le organizzazioni che monitorano gli errori di accesso senza password dovrebbero prendere in considerazione l'aggiunta del codice 1003033 alle loro query di ricerca. Si prega di notare che le informazioni disponibili con questo record sono limitate: non sarà possibile utilizzare il nome utente principale (UserPrincipalName) o altre informazioni normalmente disponibili nei registri di accesso.
- Un appello ai cloud (incluso Microsoft): iniziate a considerare i log come una funzionalità di sicurezza fondamentale da cui dipendono molti attori. Documentate accuratamente i registri dei log, completate le informazioni mancanti e comunicate eventuali modifiche apportate. Ciò aiuterà i vostri clienti e i fornitori di soluzioni di sicurezza nella loro lotta per garantire la sicurezza di tutti.
L'autore desidera ringraziare Peter Schaub e Rey Valero per il loro aiuto nella ricerca su questo incidente.