Questa pubblicazione è una raccolta di vari scenari di attacco comuni su Microsoft Entra ID (precedentemente noto come Azure Active Directory) e di come possono essere mitigati o rilevati.
Questa pubblicazione è una raccolta di vari scenari di attacco comuni su Microsoft Entra e di come possono essere mitigati o rilevati. Tutti gli scenari, le intuizioni e i commenti inclusi si basano sulle esperienze dei contributori durante le loro simulazioni di attacco, attività pratiche o scenari reali.
Dovrebbe essere considerato un documento vivo, che verrà aggiornato man mano che le pratiche progrediscono e le tecniche di attacco e difesa cambiano. Invitiamo esperti di identità o sicurezza della community a collaborare a questa pubblicazione e a contribuire con aggiornamenti, feedback, commenti o ulteriori aggiunte.
In tutti i capitoli, seguiamo le stesse linee guida sulla struttura del capitolo. Durante la lettura, ti aspetterai di trovare:
Le sezioni seguenti contengono una breve descrizione di ogni capitolo che puoi trovare nel 'Playbook di attacco e difesa Entra ID'.
L'idea iniziale per creare il 'Azure AD Attack & Defense Playbook' è venuta da Thomas Naunheim. La nostra prima chiamata su Teams è avvenuta nell'autunno del 2020, quando Thomas ha presentato l'idea ed è stata accolta immediatamente.
Il primo capitolo riguardava l'attacco 'Password Spray', in cui ci siamo concentrati molto sul meccanismo di rilevamento di Entra ID Protection (precedentemente noto come Azure AD Identity Protection) per rilevare attacchi di tipo 'password spray'. Durante il primo capitolo abbiamo imparato che il tempo di calendario per finalizzare la ricerca potrebbe richiedere molto più tempo del previsto a causa della complessità della ricerca e dei diversi punti di vista sulla ricerca. La definizione dell'ambito, come in qualsiasi tipo di lavoro di progetto, è estremamente importante.
Con gli ultimi capitoli abbiamo avuto la fortuna di avere altri membri della community coinvolti nel progetto, come Joosua Santasalo, Fabian Bader e Christopher Brumm, come partner di confronto e revisori.
Il framework MITRE ATT&CK Framework è comunemente utilizzato per mappare Tattiche, Tecniche e Procedure (TTP) delle azioni avversarie e per emulare le difese nelle organizzazioni di tutto il mondo. In questo playbook, utilizziamo il framework MITRE ATT&CK v11 in tutti i capitoli per mappare Tattiche, Tecniche e Procedure (TTP) agli scenari di attacco. Questo aiuterà i Blue Team a costruire difese per gli scenari corrispondenti.
Puoi aspettarti di trovare più regole di rilevamento nei singoli capitoli in base allo specifico scenario di attacco. Poiché il playbook ha un numero elevato di regole di rilevamento, abbiamo deciso di creare una visualizzazione che contenga tutti gli scenari di attacco mappati alle TTP. Tieni inoltre presente che ogni singolo capitolo ha una visualizzazione per il corrispondente scenario di attacco.
Apri in MITRE ATT&CK Navigator
Le relative capacità di rilevamento dei prodotti di sicurezza Microsoft (Microsoft Defender XDR, Microsoft Sentinel, Azure Entra ID Connect, Microsoft Defender for Cloud) saranno trattate nella parte di rilevamento degli scenari di attacco. Anche i modelli di regole personalizzati per Microsoft Sentinel, sviluppati per il playbook, sono mappati alle TTP. Le regole di rilevamento sono disponibili come Modello di regola di Microsoft Sentinel (pronto per la distribuzione) in formato JSON (modello ARM) qui.
Apri in MITRE ATT&CK Navigator
Nota a margine: abbiamo utilizzato la mappatura TTP esistente dai modelli di regole di Microsoft Sentinel e dalla correlazione degli incidenti di Microsoft 365. Alcuni rilevamenti non offrono una copertura completa MITRE ATT&CK e non sono inclusi in questa visualizzazione.
In genere, un capitolo ha richiesto circa 1-2 mesi di tempo di calendario, quindi è stato un notevole sforzo mettere insieme tutti e quattro (4) i capitoli e l'appendice. Durante gli ultimi due (2) anni abbiamo fatto ricerche sui seguenti scenari:
“Un attacco password spray consiste nell'attaccare più nomi utente utilizzando password comuni in modo unificato da forza bruta per ottenere accessi non autorizzati.”
Il capitolo è stato inizialmente creato a novembre 2020 e aggiornato a novembre 2021 per includere gli ultimi aggiornamenti dei prodotti di sicurezza di Microsoft Ignite 2021.
Il capitolo contiene una breve descrizione dell'attacco e degli strumenti utilizzati per simulare l'attacco di tipo password spray. Nella parte di rilevamento vengono utilizzate più soluzioni di sicurezza Microsoft come Microsoft Sentinel e Defender for Cloud Apps.
A margine, ci sono alcune considerazioni anche per l'ambiente on-premise e per ADFS, se ancora in uso.
“In un attacco di concessione del consenso illecita, l'attaccante crea un'applicazione registrata in Azure che richiede l'accesso a dati come informazioni di contatto, email o documenti. L'attaccante induce quindi un utente finale a concedere a tale applicazione il consenso per accedere ai propri dati, tramite un attacco di phishing o iniettando codice illecito in un sito web affidabile. Dopo che all'applicazione illecita è stato concesso il consenso, essa ha accesso a livello di account ai dati senza la necessità di un account organizzativo.
Le normali misure di rimedio, come reimpostare le password degli account compromessi o richiedere l'autenticazione multifattore (MFA) sugli account, non sono efficaci contro questo tipo di attacco, poiché si tratta di applicazioni di terze parti ed esterne all'organizzazione. Questi attacchi sfruttano un modello di interazione che presume che l'entità che chiama le informazioni sia automazione e non un essere umano.”
Il capitolo contiene una descrizione dell'attacco e una spiegazione del perché sia importante proteggere e monitorare le attività relative al framework di consenso di Entra ID. Nel capitolo sul rilevamento abbiamo utilizzato le seguenti soluzioni:
Poiché l'argomento è vasto e complicato, la parte di mitigazione contiene istruzioni e dettagli su come ridurre la superficie di attacco nel tuo ambiente.
Nei seguenti due scenari di attacco, ci siamo concentrati sui service principal privilegiati come parte delle pipeline di rilascio in Azure DevOps (ADO) e sulla (potenziale) visibilità limitata nell'auditing.
ADO è un argomento ampio e in questo capitolo l'ambito è limitato solo agli scenari sopra menzionati. Qui è stato seguito lo stesso percorso:
Quando abbiamo lavorato a questo capitolo, abbiamo dedicato molto tempo alle tecniche di rilevamento, che sono risultate complicate principalmente a causa dello schema del log di audit di ADO. Tuttavia, il duro lavoro ripaga e siamo riusciti a raggiungere il nostro obiettivo e a rilevare attacchi in Microsoft Sentinel.
Il capitolo contiene informazioni approfondite su come proteggere l'ambiente Azure DevOps nella sezione dedicata alla mitigazione.
In questo documento ci concentriamo principalmente sul seguente scenario:
Fuori ambito sono l'escalation dei privilegi e i percorsi di attacco dal server AADC verso Active Directory (incluso l'abuso dell'account connector di Azure AD DS)
L'ultimo capitolo, pubblicato il 14 marzo 2022, riguarda l'abuso dell'account del servizio di sincronizzazione di Microsoft Entra Connect. Per essere precisi, l'account AAD Connect è responsabile dell'esecuzione delle azioni sul lato Azure AD.
L'argomento e lo scenario di attacco sono stati estremamente interessanti per il lavoro di ricerca e, anche se in passato ho lavorato molto con Microsoft Entra Connect, devo ammettere che ho imparato molto negli ultimi due (2) mesi. Abbiamo fatto alcune scoperte interessanti che non avevamo notato prima.
Se sei arrivato a leggere fin qui, ti incoraggio a dare un'occhiata alle query KQL per Microsoft Sentinel che abbiamo creato durante il nostro lavoro di ricerca.
Microsoft ha introdotto Windows 11 con il requisito di utilizzare un chip Trusted Platform Module (TPM). Ciò ha notevolmente aumentato le capacità di utilizzare le funzionalità di sicurezza del sistema operativo Windows 11, inclusa un'ulteriore protezione per gli scenari di autenticazione basati su cloud. Il token di aggiornamento primario (PRT) e altre chiavi rilevanti possono essere ben protetti da TPM in Windows 11, ma anche in Windows 10 e nelle versioni di Windows Server dal 2016 in poi. Tenendo conto di ciò, in questo documento ci concentriamo principalmente sui seguenti scenari:
Lo scopo di Entra ID Security Config Analyzer è fornire una soluzione che estrae la configurazione di sicurezza di Entra ID dagli endpoint selezionati dell'API Microsoft Graph e inserisce i dati in Log Analytics. Azure Workbook viene utilizzato per la visualizzazione dei dati e Microsoft Sentinel può essere utilizzato per creare avvisi/incidenti quando viene rilevata una modifica critica della configurazione.
La seguente immagine descrive l'architettura della soluzione EIDSCA, la soluzione utilizzata e i flussi di dati:
Architettura di riferimento per integrare EIDSCA come parte dell'ambiente Microsoft Sentinel. I dati verranno inseriti nello stesso workspace di Sentinel. Dipende dall'implementazione e dal design se si desidera avere un'integrazione con un workspace Sentinel dedicato, operativo o esistente.
I controlli EIDSCA sono utilizzati anche in Maester, maggiori informazioni nella documentazione di Maester
Token diversi svolgono un ruolo cruciale nell'autenticazione cloud. Pertanto, è importante comprendere i loro meccanismi e come gli avversari possono sfruttarli se finiscono nelle mani sbagliate. Comprendere questo può aiutare a costruire una protezione contro gli attacchi all'identità.
Il furto di token avviene quando un avversario ottiene l'accesso e compromette i token. Una volta rubati, l'avversario può riprodurre i token rubati e accedere all'account compromesso. Nello scenario AiTM, l'avversario può aggirare il requisito MFA, perché le attestazioni MFA sono già incluse nel token e i requisiti di autenticazione sono soddisfatti. Pertanto, l'avversario ottiene l'accesso all'ambiente. Approfondiremo lo scenario, il rilevamento e la mitigazione più avanti in questo documento.
Per trovare maggiori informazioni sui token di sicurezza di Entra ID, dai un'occhiata alle seguenti risorse Microsoft Learn:
Il capitolo del Playbook di attacco e difesa di Entra ID 'Replay of Primary Refresh (PRT) and other issued tokens from an Azure AD joined device' fa luce sul replay di PRT, token di accesso e token di aggiornamento:
In questo capitolo, ci concentriamo sul tipo di attacco Adversary-in-the-Middle (AiTM) in cui l'avversario intercetta il cookie di sessione della vittima e successivamente lo riproduce per accedere al servizio di accesso.
I criminali informatici attualmente utilizzano tecniche di phishing AiTM per aggirare su larga scala le protezioni dell'autenticazione multifattore (MFA). Queste tecniche avanzate sono democratizzate e accresciute attraverso il modello economico criminale del phishing-as-a-service (PhaaS), che ha generato diverse offerte di servizi dal 2021.
Oggigiorno il numero di piattaforme PhaaS in grado di effettuare attacchi AiTM è continuato a crescere nel corso del 2023-2024, con servizi esistenti che aggiungono capacità AiTM alle loro piattaforme e nuovi servizi che incorporano nativamente tecniche di phishing AiTM. Sebbene le forme tradizionali di phishing delle credenziali esistano ancora, il numero di attacchi di phishing AiTM supera quelli senza questa capacità.
L'obiettivo finale del phishing AiTM è rubare le credenziali degli utenti e i cookie di sessione. I browser memorizzano i cookie di sessione per consentire agli utenti di accedere ai servizi senza dover essere autenticati ripetutamente. Il phishing AiTM prende di mira i cookie di sessione e le credenziali per aggirare le tradizionali protezioni MFA.
Maggiori informazioni su PhaaS:
Ogni servizio web moderno implementa una sessione con un utente dopo un'autenticazione riuscita, in modo che l'utente non debba autenticarsi su ogni nuova pagina che visita. Questa funzionalità di sessione è abilitata da un cookie di sessione rilasciato da un servizio di autenticazione dopo l'autenticazione iniziale. Il cookie di sessione funge da prova per il server web che l'utente è stato autenticato e mantiene una sessione attiva sul sito web.
In un attacco di phishing AiTM, un attaccante intercetta il cookie di sessione dell'utente vittima e successivamente lo riutilizza per accedere al servizio di accesso. Poiché il cookie dimostra che il controllo MFA è già stato superato (claim incluso nel token), soddisfa il requisito MFA, consentendo all'attaccante di bypassare le protezioni MFA e ottenere l'accesso all'account utente compromesso.
Nel phishing AiTM tramite reverse proxy, il proxy viene posizionato tra un utente e il sito web o l'applicazione legittima che l'utente vuole visitare (come i portali di accesso Microsoft o LinkedIn). Il reverse proxy inoltra le richieste dell'utente al servizio reale e intercetta le risposte. Questo tipo di configurazione consente all'avversario di rubare e intercettare la password della vittima e il cookie di sessione che prova la sua sessione attiva e autenticata con il sito web.
I kit di phishing che sono stati popolari tra gli avversari sono: EvilGinx, Modlishka, Muraena e "Office 365" (EvilProxy). Questi kit di phishing consentono agli avversari di effettuare attacchi di phishing AiTM utilizzando server reverse proxy.
Nota a margine: In molte campagne, l'applicazione presa di mira nei log Entra ID è stata OfficeHome.
Diagramma dell'attacco di phishing AiTM tramite reverse proxy (figura iniziale tratta dai report di Microsoft Defender XDR Threat Intelligence).
Un altro metodo AiTM è chiamato 'phishing AiTM tramite relay sincrono'. In questo tipo di attacco, una copia o un'imitazione di una pagina di accesso viene presentata alla vittima, come nei tradizionali attacchi di phishing. Se un utente inserisce le proprie credenziali in questa pagina, queste vengono memorizzate su un server controllato dall'attaccante dove sono installati l'istanza del kit di phishing e il relativo pannello di amministrazione. In pratica, significa che l'input dell'utente viene rubato, incluse le credenziali di accesso, i codici di autenticazione a due fattori (MFA) e i cookie di sessione.
I server relay sono tipicamente forniti e controllati dal gruppo di threat actor dietro lo sviluppo e dai soggetti responsabili della piattaforma PhaaS. Un esempio di questo tipo di gruppo è Storm-1295, che è dietro la piattaforma Greatness PhaaS secondo i report di Microsoft Threat Intelligence.
Diagramma del phishing AiTM tramite relay sincrono (figura iniziale tratta dai report di Microsoft Defender XDR Threat Intelligence).
Aggiornamento o nuovo contenuto (Pull Request): Come già accennato, ci piace avere un documento vivo guidato dalla community Entra! Condividi i tuoi risultati e le tue intuizioni come parte di questo progetto! Invia una pull request per aggiungere i tuoi contenuti a questo progetto.
Issue/Contenuti obsoleti: Le funzionalità di protezione o gli strumenti cambiano continuamente. Aggiorna i contenuti obsoleti (tramite pull request) o crea un'issue per segnalarli
Revisore: Cerchiamo anche esperti che vogliano rivedere o discutere i contenuti esistenti o nuovi prima della pubblicazione!
Feedback: Non esitare a suggerire scenari di attacco/difesa che potrebbero essere interessanti per la community. Li aggiungeremo al backlog e alla raccolta di idee!
Questo è un progetto guidato dalla community e non una soluzione o un prodotto ufficiale. Il codice o qualsiasi altro esempio di query è fornito "COSÌ COM'È" senza garanzie di alcun tipo, esplicite o implicite, incluse, a titolo esemplificativo, le garanzie implicite di commerciabilità e/o idoneità per uno scopo particolare. Questo esempio non è supportato da alcun programma o servizio di supporto. Inoltre, decliniamo ogni garanzia implicita, incluse, senza limitazione, le garanzie implicite di commerciabilità o idoneità per uno scopo particolare. Ogni rischio derivante dall'uso o dalle prestazioni dell'esempio e della documentazione rimane a carico dell'utente. In nessun caso noi, i suoi autori o chiunque altro coinvolto nella creazione, produzione o distribuzione dello script saremo responsabili per danni di qualsiasi tipo (incluse, senza limitazione, perdite di profitti aziendali, interruzioni di attività, perdita di informazioni aziendali o altre perdite pecuniarie) derivanti dall'uso o dall'impossibilità di utilizzare l'esempio o la documentazione, anche se Microsoft è stata avvisata della possibilità di tali danni.
 Sami Lamppu 💬 📖 |  Thomas Naunheim 💬 📖 |
 Joosua Santasalo 💬 📖 |  Markus Pitkäranta 💬 📖 |  Christopher Brumm 💬 📖 |  Fabian Bader 💬 📖 |  Nestori Syynimaa 💬 📖 |  Robbe Van den Daele 💬 📖 |
