Ripristino da una compromissione dell'identità sistemica
Questo articolo descrive le risorse Microsoft e le raccomandazioni per il ripristino da un attacco di compromissione dell'identità sistemica contro l'organizzazione che può verificarsi durante un attacco ransomware.
Il contenuto di questo articolo è basato sulle linee guida fornite dal team di risposta agli eventi imprevisti Microsoft (in precedenza DART/CRSP), che funziona per rispondere ai compromessi e aiutare i clienti a diventare resilienti al cyber-resiliente. Per altre indicazioni del team di risposta agli eventi imprevisti Microsoft, vedere la serie di blog sulla sicurezza Microsoft.
Molte organizzazioni hanno eseguito la transizione a un approccio basato sul cloud per una maggiore sicurezza sulla gestione delle identità e degli accessi. Tuttavia, l'organizzazione potrebbe avere anche sistemi locali e usare diversi metodi di architettura ibrida. Questo articolo riconosce che gli attacchi di identità sistemici influiscono sui sistemi cloud, locali e ibridi e fornisce raccomandazioni e riferimenti per tutti questi ambienti.
Importante
Queste informazioni vengono fornite così come sono e costituiscono indicazioni generalizzate; la determinazione finale su come applicare queste linee guida all'ambiente IT e ai tenant deve considerare l'ambiente e le esigenze univoci, che ogni cliente è nella posizione migliore da determinare.
Informazioni sulla compromissione dell'identità sistemica
Un attacco di compromissione dell'identità sistemica in un'organizzazione si verifica quando un utente malintenzionato ottiene correttamente un punto di controllo nell'amministrazione dell'infrastruttura di identità di un'organizzazione.
Se ciò è accaduto all'organizzazione, si è in una gara contro l'utente malintenzionato per proteggere l'ambiente prima di poter eseguire ulteriori danni.
Gli utenti malintenzionati con controllo amministrativo dell'infrastruttura di identità di un ambiente possono usare tale controllo per creare, modificare o eliminare identità e autorizzazioni di identità in tale ambiente.
In una compromissione locale, se i certificati di firma token SAML attendibili non vengono archiviati in un modulo di protezione hardware, l'attacco include l'accesso a tale certificato di firma token SAML attendibile.
Gli utenti malintenzionati possono quindi usare il certificato per forgiare i token SAML per rappresentare uno qualsiasi degli utenti e degli account esistenti dell'organizzazione senza richiedere l'accesso alle credenziali dell'account e senza lasciare tracce.
L'accesso con account con privilegi elevati può essere usato anche per aggiungere credenziali controllate dall'utente malintenzionato alle applicazioni esistenti, consentendo agli utenti malintenzionati di accedere al sistema non rilevato, ad esempio per chiamare le API, usando tali autorizzazioni.
Risposta all'attacco
La risposta ai compromessi di identità sistemici deve includere i passaggi illustrati nell'immagine e nella tabella seguenti:
| Procedi | Descrizione |
|---|---|
| Stabilire comunicazioni sicure | Un'organizzazione che ha sperimentato una compromissione sistemica dell'identità deve presupporre che tutte le comunicazioni siano interessate. Prima di eseguire qualsiasi azione di ripristino, è necessario assicurarsi che i membri del team chiave per l'indagine e il lavoro di risposta possano comunicare in modo sicuro. La protezione delle comunicazioni deve essere il primo passaggio, in modo da poter procedere senza la conoscenza dell'utente malintenzionato. |
| Analizzare l'ambiente | Dopo aver protetto le comunicazioni nel team di indagine principale, è possibile iniziare a cercare i punti di accesso iniziali e le tecniche di persistenza. Identificare le indicazioni di compromissione e quindi cercare i punti di accesso iniziali e la persistenza. Allo stesso tempo, iniziare a stabilire operazioni di monitoraggio continuo durante le attività di ripristino. |
| Migliorare il comportamento di sicurezza | Abilitare funzionalità e funzionalità di sicurezza seguendo le raccomandazioni sulle procedure consigliate per migliorare la sicurezza del sistema in futuro. Assicurarsi di continuare le attività di monitoraggio continuo man mano che il tempo passa e le modifiche apportate al panorama della sicurezza. |
| Ripristina/mantieni il controllo | È necessario ripristinare il controllo amministrativo dell'ambiente da parte dell'utente malintenzionato. Dopo aver nuovamente controllato e aver aggiornato il comportamento di sicurezza del sistema, assicurarsi di correggere o bloccare tutte le possibili tecniche di persistenza e nuovi exploit di accesso iniziale. |
Stabilire comunicazioni sicure
Prima di iniziare a rispondere, è necessario assicurarsi di poter comunicare in modo sicuro senza intercettazioni da parte dell'utente malintenzionato. Assicurarsi di isolare tutte le comunicazioni correlate all'evento imprevisto in modo che l'utente malintenzionato non venga tipped-off per l'indagine e venga preso a sorpresa dalle azioni di risposta.
Ad esempio:
Per le comunicazioni iniziali one-on-one e di gruppo, è possibile usare chiamate PSTN, bridge di conferenza non connessi all'infrastruttura aziendale e soluzioni di messaggistica end-to-end crittografate.
Le comunicazioni esterne a questi framework devono essere considerate compromesse e non attendibili, a meno che non vengano verificate tramite un canale sicuro.
Dopo queste conversazioni iniziali, è possibile creare un tenant di Microsoft 365 completamente nuovo, isolato dal tenant di produzione dell'organizzazione. Creare account solo per il personale chiave che deve far parte della risposta.
Se si crea un nuovo tenant di Microsoft 365, assicurarsi di seguire tutte le procedure consigliate per il tenant e in particolare per gli account e i diritti amministrativi. Limitare i diritti amministrativi, senza trust per applicazioni o fornitori esterni.
Importante
Assicurarsi di non comunicare sul nuovo tenant nell'account di posta elettronica esistente e potenzialmente compromesso.
Per altre informazioni, vedere Procedure consigliate per l'uso sicuro di Microsoft 365.
Identificare le indicazioni di compromissione
È consigliabile che i clienti seguano gli aggiornamenti dai provider di sistema, inclusi Microsoft e tutti i partner, e implementino nuovi rilevamenti e protezioni forniti e identifichino gli eventi imprevisti pubblicati di compromissione (IOC).
Verificare la disponibilità di aggiornamenti nei prodotti di sicurezza Microsoft seguenti e implementare le modifiche consigliate:
- Microsoft Sentinel
- Soluzioni e servizi di sicurezza di Microsoft 365
- Windows 10 Enterprise Security
- app Microsoft Defender per il cloud
- Microsoft Defender per IoT
L'implementazione di nuovi aggiornamenti consentirà di identificare eventuali campagne precedenti e impedire future campagne contro il sistema. Tenere presente che gli elenchi di IOC potrebbero non essere esaustivi e possono espandersi man mano che le indagini continuano.
Pertanto, è consigliabile eseguire anche le azioni seguenti:
Assicurarsi di aver applicato il benchmark della sicurezza cloud Microsoft e di monitorare la conformità tramite Microsoft Defender per il cloud.
Incorporare i feed di intelligence per le minacce nel sistema SIEM, ad esempio configurando i connettori dati di Microsoft Purview in Microsoft Sentinel.
Assicurarsi che tutti gli strumenti di rilevamento e risposta estesi, ad esempio Microsoft Defender per IoT, usino i dati di intelligence sulle minacce più recenti.
Per altre informazioni, vedere la documentazione sulla sicurezza di Microsoft:
Analizzare l'ambiente
Una volta che i responsabili degli eventi imprevisti e il personale chiave hanno un posto sicuro per collaborare, è possibile iniziare a analizzare l'ambiente compromesso.
Sarà necessario bilanciare il recupero fino alla fine di ogni comportamento anomalo e intraprendere un'azione rapida per arrestare qualsiasi altra attività da parte dell'utente malintenzionato. Qualsiasi correzione corretta richiede una conoscenza del metodo iniziale di immissione e dei metodi di persistenza usati dall'utente malintenzionato, il più completo possibile al momento. Qualsiasi metodo di persistenza perso durante l'indagine può comportare un accesso continuo da parte dell'utente malintenzionato e una potenziale ricompromise.
A questo punto, è consigliabile eseguire un'analisi dei rischi per classificare in ordine di priorità le azioni. Per altre informazioni, vedi:
- Valutazione delle minacce, della vulnerabilità e dei rischi del data center
- Tenere traccia delle minacce emergenti e rispondere alle minacce analitica
- Gestione di minacce e vulnerabilità
I servizi di sicurezza Microsoft offrono risorse complete per indagini dettagliate. Le sezioni seguenti descrivono le azioni consigliate principali.
Nota
Se si ritiene che una o più origini di registrazione elencate non facciano attualmente parte del programma di sicurezza, è consigliabile configurarle il prima possibile per abilitare i rilevamenti e le verifiche dei log future.
Assicurarsi di configurare la conservazione dei log per supportare gli obiettivi di indagine dell'organizzazione in futuro. Conservare le prove necessarie per scopi legali, normativi o assicurativi.
Analizzare ed esaminare i log dell'ambiente cloud
Analizzare ed esaminare i log dell'ambiente cloud per individuare azioni sospette e indicazioni di compromissione da parte di utenti malintenzionati. Ad esempio, controllare i log seguenti:
- Log di controllo unificati
- Log di Microsoft Entra
- Log locali di Microsoft Exchange
- Log VPN, ad esempio da Gateway VPN
- Log di sistema di progettazione
- Log di rilevamento degli endpoint e antivirus
Esaminare i log di controllo degli endpoint
Esaminare i log di controllo dell'endpoint per le modifiche locali, ad esempio i tipi di azioni seguenti:
- Modifiche all'appartenenza ai gruppi
- Creazione di un nuovo account utente
- Deleghe all'interno di Active Directory
In particolare, prendere in considerazione una qualsiasi di queste modifiche che si verificano insieme ad altri segni tipici di compromissione o attività.
Esaminare i diritti amministrativi negli ambienti
Esaminare i diritti amministrativi sia negli ambienti cloud che locali. Ad esempio:
| Environment | Descrizione |
|---|---|
| Tutti gli ambienti cloud | - Esaminare eventuali diritti di accesso con privilegi nel cloud e rimuovere eventuali autorizzazioni non necessarie - Implementare Privileged Identity Management (PIM) - Configurare i criteri di accesso condizionale per limitare l'accesso amministrativo durante la protezione avanzata |
| Tutti gli ambienti locali | - Esaminare l'accesso con privilegi in locale e rimuovere autorizzazioni non necessarie - Ridurre l'appartenenza ai gruppi predefiniti - Verificare le deleghe di Active Directory - Rafforzare l'ambiente di livello 0 e limitare chi può accedere agli asset di livello 0 |
| Tutte le applicazioni aziendali | Esaminare le autorizzazioni delegate e le concessioni di consenso che consentono una delle azioni seguenti: - Modifica di utenti e ruoli con privilegi - Lettura o accesso a tutte le cassette postali - Invio o inoltro di posta elettronica per conto di altri utenti - Accesso a tutti i contenuti del sito di OneDrive o SharePoint - Aggiunta di entità servizio in grado di leggere/scrivere nella directory |
| Ambienti Microsoft 365 | Esaminare le impostazioni di accesso e configurazione per l'ambiente Microsoft 365, tra cui: - Condivisione di SharePoint Online - Microsoft Teams - Power Apps - Microsoft OneDrive for Business |
| Esaminare gli account utente negli ambienti | - Esaminare e rimuovere gli account utente guest non più necessari. - Esaminare le configurazioni di posta elettronica per delegati, autorizzazioni per le cartelle delle cassette postali, registrazioni dei dispositivi mobili ActiveSync, regole posta in arrivo e Opzioni di Outlook sul Web. - Esaminare i diritti applicationImpersonation e ridurre il più possibile l'uso dell'autenticazione legacy. - Verificare che l'autenticazione a più fattori sia applicata e che le informazioni di contatto di reimpostazione della password self-service e MFA siano corrette per tutti gli utenti. |
Stabilire il monitoraggio continuo
Il rilevamento del comportamento degli utenti malintenzionati include diversi metodi e dipende dagli strumenti di sicurezza disponibili per rispondere all'attacco.
Ad esempio, i servizi di sicurezza Microsoft possono avere risorse e linee guida specifiche rilevanti per l'attacco, come descritto nelle sezioni seguenti.
Importante
Se l'indagine rileva la prova delle autorizzazioni amministrative acquisite tramite la compromissione nel sistema, che ha fornito l'accesso all'account amministratore globale dell'organizzazione e/o al certificato di firma del token SAML attendibile, è consigliabile intervenire per correggere e mantenere il controllo amministrativo.
Monitoraggio con Microsoft Sentinel
Microsoft Sentinel include molte risorse predefinite per facilitare l'analisi, ad esempio le cartelle di lavoro di ricerca e le regole di analitica che consentono di rilevare gli attacchi nelle aree pertinenti dell'ambiente.
Usare l'hub del contenuto di Microsoft Sentinel per installare soluzioni di sicurezza estese e connettori dati che eseguono lo streaming di contenuto da altri servizi nell'ambiente in uso. Per altre informazioni, vedi:
- Visualizzare e analizzare l'ambiente
- Rilevare le minacce predefinite
- Individuare e distribuire soluzioni predefinite
Monitoraggio con Microsoft Defender per IoT
Se l'ambiente include anche risorse OT (Operational Technology), è possibile che siano presenti dispositivi che usano protocolli specializzati, che assegnano priorità alle sfide operative sulla sicurezza.
Distribuire Microsoft Defender per IoT per monitorare e proteggere tali dispositivi, in particolare quelli che non sono protetti dai sistemi di monitoraggio della sicurezza tradizionali. Installare i sensori di rete defender per IoT in punti specifici di interesse nell'ambiente per rilevare le minacce nell'attività di rete in corso usando il monitoraggio senza agente e l'intelligence dinamica sulle minacce.
Per altre informazioni, vedere Introduzione al monitoraggio della sicurezza di rete OT.
Monitoraggio con Microsoft Defender XDR
È consigliabile controllare Microsoft Defender XDR per Endpoint e Antivirus Microsoft Defender per indicazioni specifiche relative all'attacco.
Verificare la presenza di altri esempi di rilevamenti, query di ricerca e report di analitica sulle minacce nel Centro sicurezza Microsoft, ad esempio in Microsoft Defender XDR, Microsoft Defender XDR per identità e Microsoft Defender per il cloud App. Per garantire la copertura, assicurarsi di installare l'agente Microsoft Defender per identità nei server ADFS oltre a tutti i controller di dominio.
Per altre informazioni, vedi:
- Tenere traccia delle minacce emergenti e rispondere alle minacce analitica
- Comprendere il report analista nel analitica delle minacce
Monitoraggio con Microsoft Entra ID
I log di accesso di Microsoft Entra possono indicare se l'autenticazione a più fattori viene usata correttamente. Accedere ai log di accesso direttamente dall'area di Microsoft Entra nella portale di Azure, usare il cmdlet Get-MgBetaAuditLogSignIn o visualizzarli nell'area Log di Microsoft Sentinel.
Ad esempio, cercare o filtrare i risultati quando il campo dei risultati MFA ha un valore del requisito MFA soddisfatto dall'attestazione nel token. Se l'organizzazione usa ADFS e le attestazioni registrate non sono incluse nella configurazione di ADFS, queste attestazioni possono indicare l'attività dell'utente malintenzionato.
Cercare o filtrare ulteriormente i risultati per escludere il rumore aggiuntivo. Ad esempio, è possibile includere i risultati solo dai domini federati. Se si trovano accessi sospetti, eseguire il drill-down ancora più in base a indirizzi IP, account utente e così via.
La tabella seguente descrive altri metodi per l'uso dei log di Microsoft Entra nell'indagine:
| metodo | Descrizione |
|---|---|
| Analizzare gli eventi di accesso rischiosi | Microsoft Entra ID e la relativa piattaforma Identity Protection possono generare eventi di rischio associati all'uso di token SAML generati da utenti malintenzionati. Questi eventi potrebbero essere etichettati come proprietà sconosciute, indirizzo IP anonimo, viaggio impossibile e così via. È consigliabile analizzare attentamente tutti gli eventi di rischio associati agli account con privilegi amministrativi, inclusi quelli che potrebbero essere stati ignorati o risolti automaticamente. Ad esempio, un evento di rischio o un indirizzo IP anonimo potrebbe essere corretto automaticamente perché l'utente ha passato l'autenticazione a più fattori. Assicurarsi di usare ADFS Connect Health in modo che tutti gli eventi di autenticazione siano visibili in Microsoft Entra ID. |
| Rilevare le proprietà di autenticazione del dominio | Qualsiasi tentativo da parte dell'utente malintenzionato di modificare i criteri di autenticazione del dominio verrà registrato nei log di controllo di Microsoft Entra e si riflette nel log di controllo unificato. Esaminare, ad esempio, gli eventi associati all'impostazione dell'autenticazione del dominio nel log di controllo unificato, nei log di controllo di Microsoft Entra e/o nell'ambiente SIEM per verificare che tutte le attività elencate siano previste e pianificate. |
| Rilevare le credenziali per le applicazioni OAuth | Gli utenti malintenzionati che hanno ottenuto il controllo di un account con privilegi possono cercare un'applicazione con la possibilità di accedere alla posta elettronica di qualsiasi utente nell'organizzazione e quindi aggiungere credenziali controllate dall'utente malintenzionato a tale applicazione. Ad esempio, è possibile cercare una delle attività seguenti, che sarebbero coerenti con il comportamento dell'utente malintenzionato: - Aggiunta o aggiornamento delle credenziali dell'entità servizio - Aggiornamento di certificati e segreti dell'applicazione - Aggiunta di una concessione di ruolo dell'app a un utente - Aggiunta di Oauth2PermissionGrant |
| Rilevare l'accesso alla posta elettronica da parte delle applicazioni | Cercare l'accesso alla posta elettronica da parte delle applicazioni nell'ambiente. Ad esempio, usare le funzionalità di Microsoft Purview Audit (Premium) per analizzare gli account compromessi. |
| Rilevare accessi non interattivi alle entità servizio | I report di accesso di Microsoft Entra forniscono informazioni dettagliate sugli accessi non interattivi che usano le credenziali dell'entità servizio. Ad esempio, è possibile usare i report di accesso per trovare dati importanti per l'indagine, ad esempio un indirizzo IP usato dall'utente malintenzionato per accedere alle applicazioni di posta elettronica. |
Migliorare il comportamento di sicurezza
Se si è verificato un evento di sicurezza nei sistemi, è consigliabile riflettere sulla strategia e sulle priorità di sicurezza correnti.
Gli addetti alle risposte agli eventi imprevisti vengono spesso invitati a fornire raccomandazioni sugli investimenti che l'organizzazione deve classificare in ordine di priorità, ora che è stata affrontata con nuove minacce.
Oltre alle raccomandazioni documentate in questo articolo, è consigliabile prendere in considerazione la priorità delle aree di attenzione che rispondono alle tecniche di post-sfruttamento usate da questo utente malintenzionato e alle lacune comuni del comportamento di sicurezza che le consentono.
Le sezioni seguenti elencano le raccomandazioni per migliorare sia il comportamento generale che quello di sicurezza delle identità.
Migliorare il comportamento di sicurezza generale
Per garantire il comportamento di sicurezza generale, è consigliabile eseguire le azioni seguenti:
Vedere Microsoft Secure Score per consigli sui concetti fondamentali sulla sicurezza personalizzati per i prodotti e i servizi Microsoft utilizzati.
Assicurarsi che l'organizzazione disponga di soluzioni di rilevamento e risposta estese (XDR) e informazioni di sicurezza e gestione degli eventi (SIEM), ad esempio Microsoft Defender XDR per endpoint, Microsoft Sentinel e Microsoft Defender per IoT.
Esaminare il modello di accesso Enterprise di Microsoft
Migliorare il comportamento di sicurezza delle identità
È consigliabile eseguire le azioni seguenti per garantire il comportamento di sicurezza correlato all'identità:
Esaminare i cinque passaggi di Microsoft per proteggere l'infrastruttura di gestione delle identità e definire in ordine di priorità i passaggi appropriati per l'architettura delle identità.
Valutare la possibilità di eseguire la migrazione alle impostazioni predefinite di Microsoft Entra Security per i criteri di autenticazione.
Eliminare l'uso dell'autenticazione legacy dell'organizzazione, se i sistemi o le applicazioni lo richiedono ancora. Per altre informazioni, vedere Bloccare l'autenticazione legacy a Microsoft Entra ID con l'accesso condizionale.
Considerare l'infrastruttura ADFS e l'infrastruttura AD Connect come asset di livello 0.
Limitare l'accesso amministrativo locale al sistema, incluso l'account usato per eseguire il servizio ADFS.
Il privilegio minimo necessario per l'account che esegue ADFS è l'assegnazione del diritto utente accesso come servizio .
Limitare l'accesso amministrativo a utenti limitati e da intervalli di indirizzi IP limitati usando i criteri di Windows Firewall per Desktop remoto.
È consigliabile configurare un jump box di livello 0 o un sistema equivalente.
Bloccare l'accesso SMB in ingresso ai sistemi da qualsiasi posizione dell'ambiente. Per altre informazioni, vedere Beyond the Edge: How to Secure SMB Traffic in Windows(Oltre edge: Come proteggere il traffico SMB in Windows). È anche consigliabile trasmettere i log di Windows Firewall a un siem per il monitoraggio cronologico e proattivo.
Se si usa un account del servizio e il supporto ambientale, eseguire la migrazione da un account del servizio a un account del servizio gestito di gruppo. Se non è possibile passare a un account del servizio gestito del gruppo, ruotare la password nell'account del servizio su una password complessa.
Verificare che la registrazione dettagliata sia abilitata nei sistemi ADFS.
Correggere e mantenere il controllo amministrativo
Se l'indagine ha rilevato che l'utente malintenzionato ha il controllo amministrativo nel cloud o nell'ambiente locale dell'organizzazione, è necessario riprendere il controllo in modo da garantire che l'utente malintenzionato non sia persistente.
Questa sezione fornisce i metodi e i passaggi possibili da considerare quando si compila il piano di ripristino del controllo amministrativo.
Importante
I passaggi esatti richiesti nell'organizzazione dipendono dalla persistenza individuata nell'indagine e dalla certezza che l'indagine sia stata completata e abbia individuato tutti i possibili metodi di immissione e persistenza.
Assicurarsi che tutte le azioni eseguite vengano eseguite da un dispositivo attendibile, compilate da un'origine pulita. Ad esempio, usare una workstation di accesso con privilegi aggiornata.
Le sezioni seguenti includono i tipi di raccomandazioni seguenti per la correzione e la conservazione del controllo amministrativo:
- Rimozione dell'attendibilità nei server correnti
- Rotazione del certificato di firma del token SAML o sostituzione dei server ADFS, se necessario
- Attività di correzione specifiche per ambienti cloud o locali
Rimuovere l'attendibilità nei server correnti
Se l'organizzazione ha perso il controllo dei certificati di firma token o dell'attendibilità federata, l'approccio più sicuro consiste nel rimuovere l'attendibilità e passare all'identità gestita dal cloud durante la correzione locale.
La rimozione dell'attendibilità e del passaggio all'identità gestita dal cloud richiede un'attenta pianificazione e una conoscenza approfondita degli effetti operativi aziendali dell'isolamento dell'identità. Per altre informazioni, vedere Protezione di Microsoft 365 dagli attacchi locali.
Ruotare il certificato di firma del token SAML
Se l'organizzazione decide di non rimuovere l'attendibilità durante il ripristino del controllo amministrativo locale, sarà necessario ruotare il certificato di firma del token SAML dopo aver ripristinato il controllo amministrativo in locale e bloccare di nuovo l'accesso al certificato di firma da parte degli utenti malintenzionati.
La rotazione del certificato di firma del token una sola volta consente comunque il funzionamento del certificato di firma del token precedente. Continuando a consentire il funzionamento dei certificati precedenti, è una funzionalità predefinita per le normali rotazioni dei certificati, che consente alle organizzazioni di aggiornare eventuali trust della relying party prima della scadenza del certificato.
Se si è verificato un attacco, non si vuole che l'utente malintenzionato mantenga affatto l'accesso. Assicurarsi che l'utente malintenzionato non mantenga la possibilità di forgiare i token per il dominio.
Per altre informazioni, vedi:
Sostituire i server ADFS
Se, invece di ruotare il certificato di firma del token SAML, si decide di sostituire i server ADFS con sistemi puliti, sarà necessario rimuovere l'esistente ADFS dall'ambiente e quindi crearne uno nuovo.
Per altre informazioni, vedere Rimuovere una configurazione.
Attività di correzione cloud
Oltre alle raccomandazioni elencate in precedenza in questo articolo, è consigliabile anche eseguire le attività seguenti per gli ambienti cloud:
| Impegno | Descrizione |
|---|---|
| Reimpostare le password | Reimpostare le password in tutti gli account break-glass e ridurre il numero di account break glass al minimo assoluto richiesto. |
| Limitare gli account di accesso con privilegi | Assicurarsi che gli account di servizio e utente con accesso con privilegi siano account solo cloud e non usino account locali sincronizzati o federati con Microsoft Entra ID. |
| Applicazione dell'autenticazione a più fattori | Applicare Multi-Factor Authentication (MFA) a tutti gli utenti con privilegi elevati nel tenant. È consigliabile applicare l'autenticazione a più fattori in tutti gli utenti nel tenant. |
| Limitare l'accesso amministrativo | Implementare Privileged Identity Management (PIM) e l'accesso condizionale per limitare l'accesso amministrativo. Per gli utenti di Microsoft 365, implementare Privileged Access Management (PAM) per limitare l'accesso alle capacità sensibili, ad esempio eDiscovery, Amministratore globale, Amministrazione account e altro ancora. |
| Esaminare/ridurre le autorizzazioni delegate e le concessioni di consenso | Esaminare e ridurre tutte le autorizzazioni delegate o le concessioni di consenso di applicazioni aziendali che consentono una delle funzionalità seguenti: - Modifica di utenti e ruoli con privilegi - Lettura, invio di posta elettronica o accesso a tutte le cassette postali - Accesso al contenuto di OneDrive, Teams o SharePoint - Aggiunta di entità servizio in grado di leggere/scrivere nella directory - Autorizzazioni dell'applicazione e accesso delegato |
Attività di correzione locali
Oltre alle raccomandazioni elencate in precedenza in questo articolo, è consigliabile anche eseguire le attività seguenti per gli ambienti locali:
| Impegno | Descrizione |
|---|---|
| Ricompilare i sistemi interessati | Ricompilare i sistemi identificati come compromessi dall'utente malintenzionato durante l'indagine. |
| Rimuovere utenti amministratori non necessari | Rimuovere membri non necessari dai gruppi Domain Admins, Backup Operators e Enterprise Admin. Per altre informazioni, vedere Protezione dell'accesso con privilegi. |
| Reimpostare le password agli account con privilegi | Reimpostare le password di tutti gli account con privilegi nell'ambiente. Nota: gli account con privilegi non sono limitati ai gruppi predefiniti, ma possono anche essere gruppi che hanno accesso delegato all'amministrazione del server, all'amministrazione della workstation o ad altre aree dell'ambiente. |
| Reimpostare l'account krbtgt | Reimpostare due volte l'account krbtgt usando lo script New-KrbtgtKeys . Nota: se si usano controller di dominio di sola lettura, sarà necessario eseguire lo script separatamente per i controller di dominio di lettura-scrittura e per i controller di dominio di sola lettura. |
| Pianificare un riavvio del sistema | Dopo aver verificato che non esistano meccanismi di persistenza creati dall'utente malintenzionato o rimangano nel sistema, pianificare un riavvio del sistema per facilitare la rimozione del malware residente in memoria. |
| Reimpostare la password DSRM | Reimpostare la password DSRM di ogni controller di dominio (modalità di ripristino dei servizi directory) su un valore univoco e complesso. |
Correggere o bloccare la persistenza individuata durante l'indagine
L'indagine è un processo iterativo ed è necessario bilanciare il desiderio dell'organizzazione di correggere le anomalie e la possibilità che la correzione avviserà l'utente malintenzionato al rilevamento e darà loro tempo di reagire.
Ad esempio, un utente malintenzionato che rileva il rilevamento potrebbe modificare le tecniche o creare una maggiore persistenza.
Assicurarsi di correggere le tecniche di persistenza identificate nelle fasi precedenti dell'indagine.
Correggere l'accesso all'account utente e al servizio
Oltre alle azioni consigliate elencate sopra, è consigliabile prendere in considerazione i passaggi seguenti per correggere e ripristinare gli account utente:
Applicare l'accesso condizionale in base ai dispositivi attendibili. Se possibile, è consigliabile applicare l'accesso condizionale basato sulla posizione in base ai requisiti dell'organizzazione.
Reimpostare le password dopo la rimozione per tutti gli account utente che potrebbero essere stati compromessi. Assicurarsi di implementare anche un piano a medio termine per reimpostare le credenziali per tutti gli account nella directory.
Revocare i token di aggiornamento immediatamente dopo la rotazione delle credenziali.
Per altre informazioni, vedi:
Passaggi successivi
Ottenere assistenza dall'interno dei prodotti Microsoft, tra cui Microsoft Defender Portal, Portale di conformità di Microsoft Purview e Centro sicurezza e conformità di Office 365 selezionando il pulsante Guida (?) nella barra di spostamento superiore.
In caso di esigenze correlate al supporto tecnico del prodotto, inviare un caso di supporto Tecnico Microsoft.
Importante
Se si ritiene di essere stato compromesso e richiedere assistenza tramite una risposta agli eventi imprevisti, aprire un caso di supporto Sev A Microsoft.