Tracciare i tentativi di accesso malevoli non è semplice
Recentemente abbiamo indagato su un comportamento sospetto in un ambiente in cui era stata impostata l'autenticazione senza password di Azure. Le indagini sono state avviate perché diversi utenti sono stati colpiti da richieste inaspettate dell'applicazione Authenticator. Nessuno degli utenti è caduto nell'inganno o ha lasciato entrare l'aggressore.
Questo tipo di evento, noto come MFA Fatigue, è di routine e atteso da organizzazioni grandi e piccole. Gli aggressori sfrutteranno questa tecnica di social engineering per indurre gli utenti ad accettare le richieste di autenticazione push, che hanno avuto successo in attacchi recenti, tra cui Uber).
Lo scenario si è rivelato particolarmente difficile da indagare a causa dei record di registro associati alle richieste senza password fallite.
Le limitazioni nelle capacità di registrazione complicano le indagini.
Tracciare i tentativi di accesso malevoli è fondamentale per proteggere gli ambienti cloud ed è possibile solo monitorando i registri cloud disponibili. Sebbene Microsoft e altri fornitori di cloud pubblichino schemi di log e forniscano Service-Level Agreements (SLA) per la consegna dei registri, ci sono ancora diversi problemi che affliggono i log cloud :
- I tipi di eventi record spesso non sono ben documentati e talvolta non lo sono affatto.
- Alcuni dei valori e degli ID registrati sono interni al cloud provider e il loro significato non è chiaro.
- Vengono aggiunti nuovi tipi di record di log, i tipi di record vengono ritirati e i formati dei record vengono modificati senza preavviso per gli utenti.
Tutto ciò complica il monitoraggio e la risposta agli incidenti e lascia i consumatori cloud incerti sulla completezza dei record di log e a giocare a rimpiattino con le modifiche non annunciate; diventa quindi difficile indagare sui prompt senza password falliti dai dati registrati.
Uno sguardo ravvicinato all'individuazione e alla mitigazione dei fallimenti di accesso senza password in Azure
Autenticazione senza password
Per chi non lo sapesse, l'autenticazione senza password è un'opzione solida per ridurre il rischio che gli utenti creino password non sicure. Esistono diversi modi per abilitare l'autenticazione senza password in Azure. Nell'ambiente analizzato, è stata utilizzata l'applicazione Microsoft Authenticator.
Per iscriversi all'autenticazione senza password, gli utenti finali devono seguire questi passaggi di configurazione dettagliati. Una volta iscritto a questo metodo, l'utente può inserire il proprio nome utente nel prompt di accesso di Azure e selezionare l'opzione "Usa un'applicazione":
L'utente riceve quindi un numero da inserire nell'applicazione mobile per completare il processo:
Se il numero corrisponde, l'utente è autenticato. Oltre a essere ragionevolmente sicuro, questo metodo non richiede più agli utenti di creare e ricordare buone password, il che migliora notevolmente l'usabilità.
Indagine
In passato abbiamo monitorato diversi modi di impostare l'MFA in Azure, tra cui l'utilizzo dell'accesso senza password con Microsoft Authenticator come secondo fattore (ovvero, quando all'utente viene richiesto di accedere all'applicazione dopo aver inserito la password corretta). Microsoft Authenticator come secondo fattore osserviamo uno dei seguenti due errori nei log se le richieste di Authenticator vengono abbandonate o il codice non è corretto:
- 50074 È richiesta l'autenticazione forte.
- 500121 Autenticazione fallita durante la richiesta di autenticazione forte.
Di conseguenza, le nostre query di rilevamento e di caccia sono state impostate per cercare questi codici di errore.
Tuttavia, quando l'app Microsoft Authenticator è impostata come fattore singolo, 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 una novità, qualcosa che non avevamo mai visto prima e la ricerca su Internet non ha portato praticamente nessuna informazione sulla sua origine. Anche il messaggio di errore era criptico, senza alcuna spiegazione di cosa fosse "NGC". Dopo alcune ricerche, abbiamo stabilito che corrisponde al GUID D6886603-9D2F-4EB2-B667-1971041FA96B, documentato come "PIN Credential Provider".
Esaminando il record di registro, abbiamo notato altre incongruenze (vedi schermata sotto):
- I dettagli relativi alla posizione e al dispositivo (in rosso) non vengono compilati.
- Mancano le informazioni sulle applicazioni e sulle risorse (in blu).
- Le informazioni sull'utente (in viola) sono limitate. UserPrincipalName e UserDisplayName non sono riempiti con 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 di log rendono difficile l'individuazione di tali eventi e la loro corretta investigazione.
Mitigazione
Viste le difficoltà incontrate nell'indagare su questo incidente, abbiamo voluto condividere i dettagli raccolti con la comunità della sicurezza, in modo che i professionisti della sicurezza possano adattare le loro query di caccia per individuare questa condizione. Noi di Vectra abbiamo già aggiornato i nostri prodotti per coprire questo scenario.
La query di caccia potrebbe essere semplice come il seguente snippet di Kusto che troverà tutti i tentativi di accesso senza password falliti negli ultimi 30 giorni:
SigninLogs | dove TimeGenerated > ago(30d) | dove ResultType == 1003033
Potrebbero essere interessanti anche altri codici di errore relativi a NGC:
Da notare:
- Quando si introducono nuove modalità di autenticazione nell'ambiente, valutare i log risultanti dalle interazioni con questi nuovi meccanismi. Cercate 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 i fallimenti di accesso senza password dovrebbero considerare l'aggiunta del codice 1003033 alle loro query di caccia. Si noti che le informazioni disponibili in questo record sono limitate: non è possibile utilizzare UserPrincipalName o altre informazioni normalmente disponibili nei record del log di accesso.
- Un appello ai fornitori di cloud (inclusa Microsoft): iniziate a considerare i log come una funzione di sicurezza cruciale da cui dipendono molti attori. Documentate accuratamente i registri di log, completate le informazioni mancanti e annunciate le modifiche che state apportando. Questo aiuterà i vostri clienti e i fornitori di sicurezza nella loro lotta per mantenere tutti al sicuro.
L'autore desidera ringraziare Peter Schaub e Rey Valero per il loro aiuto nella ricerca di questo incidente.