Account compromesso

Riconosci i segnali che avviano la procedura

Obiettivo: capire velocemente se esiste un motivo concreto per aprire un incidente di identità.

1. Registra chi o cosa ha generato il segnale: utente, help desk, Microsoft Defender, Identity Protection o altro sistema.
2. Chiedi all'utente, tramite telefono o altro canale attendibile, se riconosce l'attività.
3. Apri la procedura anche con un solo segnale forte, per esempio una nuova MFA non riconosciuta o email inviate dall'account.
4. Se il segnale è debole, controlla comunque accessi e rischio prima di chiudere come falso positivo.

Esempio semplice: l'utente nega una richiesta MFA arrivata alle 09:14 nel proprio fuso orario. Registra fuso e offset, converti correttamente in UTC e cerca gli accessi precedenti. Una richiesta negata da sola non dimostra un accesso riuscito.

Completa quando: il caso ha un proprietario, un intervallo temporale iniziale e una decisione documentata tra incidente credibile e falso positivo.

Definisci urgenza, privilegi e possibile impatto

Obiettivo: capire quanto è grave il caso, cosa può raggiungere l'identità e chi deve essere coinvolto subito.

1. Identifica se l'account è cloud, sincronizzato, privilegiato, di emergenza, condiviso o usato da un servizio.
2. Controlla ruoli, gruppi sensibili, mailbox condivise, deleghe, applicazioni e dispositivi associati.
3. Chiedi all'utente quali dispositivi, paesi e applicazioni ha usato nel periodo sospetto.
4. Controlla se esistono altri utenti, messaggi, file o applicazioni collegati allo stesso incidente.
5. Assegna una priorità alta se sono presenti privilegi, frode, dati sensibili, accesso ancora attivo o più identità coinvolte.

Completa quando: priorità, proprietari, dipendenze e percorso di contenimento sono chiari e documentati.

Interrompi l'accesso e limita nuovi danni

Obiettivo: impedire all'attaccante di ottenere nuovi token, usare sessioni esistenti o registrare altri metodi di accesso.

1. Disabilita l'accesso nell'origine autorevole. Per un utente sincronizzato, applica la modifica anche nella directory locale quando necessario.
2. Revoca le sessioni per invalidare i token di aggiornamento e impedire nuove richieste di token.
3. Reimposta la password con un valore casuale e unico. Se l'identità è ibrida, completa il cambio nel sistema che gestisce la password.
4. Controlla i metodi di autenticazione e rimuovi telefoni, Authenticator, passkey, chiavi FIDO2 o pass di accesso temporanei non riconosciuti.
5. Disabilita o isola i dispositivi confermati come compromessi e avvisa il team endpoint.
6. Revoca nuovamente le sessioni dopo la pulizia dei metodi di autenticazione.

Nota sui token: la revoca blocca i token di aggiornamento, ma alcuni token di accesso o sessioni gestite direttamente dalle applicazioni possono funzionare fino alla scadenza o a una nuova valutazione.

Completa quando: l'identità non può eseguire nuovi accessi, le sessioni sono revocate, i metodi sconosciuti sono rimossi e le dipendenze critiche sono sotto controllo.

# Cloud member users only. Run after incident authorization and evidence capture.
$ErrorActionPreference = 'Stop'
Import-Module Microsoft.Graph.Users
Import-Module Microsoft.Graph.Users.Actions
$tenantId = [guid](Read-Host 'Tenant ID (GUID)')
if ($tenantId -eq [guid]::Empty) { throw 'A tenant ID is required.' }
$targetUpn = (Read-Host 'Exact user principal name to disable').Trim()
if (-not $targetUpn) { throw 'A target user is required.' }
$connected = $false
try {
  Connect-MgGraph -TenantId $tenantId -ContextScope Process -Scopes 'User.EnableDisableAccount.All','User.Read.All','User.RevokeSessions.All'
  $connected = $true
  if ([guid](Get-MgContext).TenantId -ne $tenantId) { throw 'Wrong tenant context.' }
  $target = Get-MgUser -UserId $targetUpn -Property Id,UserPrincipalName,UserType,OnPremisesSyncEnabled,AccountEnabled
  if (-not $target.Id -or $target.UserPrincipalName -ne $targetUpn -or $target.UserType -ne 'Member' -or $target.OnPremisesSyncEnabled) {
    throw 'Stop: target mismatch, guest or synchronized account. Use the appropriate workflow.'
  }
  $target | Select-Object Id,UserPrincipalName,AccountEnabled
  if ((Read-Host 'Confirm authorized action by typing the exact UPN again') -cne $target.UserPrincipalName) {
    throw 'Confirmation did not match.'
  }
  Update-MgUser -UserId $target.Id -AccountEnabled:$false
  $state = Get-MgUser -UserId $target.Id -Property AccountEnabled
  if ($state.AccountEnabled -ne $false) { throw 'Disable was not verified. Escalate before continuing.' }
  $revoked = Revoke-MgUserSignInSession -UserId $target.Id
  if ($revoked -ne $true) { throw 'Account disabled, but session revocation was not confirmed. Keep it blocked and verify in the portal.' }
} finally {
  if ($connected) { Disconnect-MgGraph }
}
# Record UTC time and action results in the incident. Existing app sessions may remain.

Costruisci la sequenza temporale e l'impatto

Parti dall'identità e procedi verso l'esterno. Prima stabilisci cosa significa l'accesso sospetto, poi indaga persistenza, posta, applicazioni, dispositivi e dati.

Cosa fare

• Completa la SOP sugli accessi sospettiRegistra la decisione Sicuro, Problema tecnico, Sospetto, Attacco esteso o Non risolto. Allega gli export originali interattivi e non interattivi, oppure documenta la lacuna di copertura.
• Controlla la persistenza nella cassetta postaleConserva regole Inbox nascoste, inoltro, deleghe, risposte automatiche e impostazioni sospette.
• Controlla i consensi delle applicazioniEsamina autorizzazioni utente e tenant. Reimpostare password e MFA non rimuove le autorizzazioni OAuth.
• Traccia posta inviata e consultataUsa message trace, Posta inviata, Threat Explorer se disponibile e gli eventi MailItemsAccessed se inclusi nella licenza.
• Esamina dati, ruoli, dispositivi e automazioniControlla l'audit rilevante di SharePoint, OneDrive, ruoli, dispositivi e Power Automate per download, condivisioni o modifiche dannose.
• Cerca attività correlateCerca lo stesso IP, applicazione, dispositivo, consenso, destinatario o schema di attacco su altre identità.

Get-InboxRule -Mailbox <UPN> -IncludeHidden |
  Format-List Name,Enabled,Description,RedirectTo,ForwardTo,ForwardAsAttachmentTo,DeleteMessage,MoveToFolder,Identity

Get-Mailbox -Identity <UPN> |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-MailboxPermission <UPN> |
  Where-Object {$_.AccessRights -like "Full*"} |
  Format-Table User,Deny,IsInherited,AccessRights -Auto

Get-RecipientPermission -Identity <UPN>
Get-Mailbox -Identity <UPN> | Format-List GrantSendOnBehalfTo

Rimuovi la causa e ogni accesso residuo

Obiettivo: eliminare credenziali, configurazioni, applicazioni e contenuti dannosi senza perdere le evidenze necessarie.

1. Ruota password, segreti e credenziali collegate. Non riutilizzare password precedenti.
2. Rimuovi metodi MFA sconosciuti e fai registrare nuovamente quelli approvati da un dispositivo attendibile.
3. Elimina regole, moduli Outlook, inoltri, deleghe e autorizzazioni mailbox non autorizzati dopo averli documentati.
4. Disabilita l'applicazione dannosa e revoca i consensi. La sola eliminazione dell'app non garantisce che il consenso non venga ricreato.
5. Rimuovi ruoli, gruppi, dispositivi o modifiche di configurazione introdotti dall'attaccante.
6. Usa Explorer o Ricerca avanzata per correggere i messaggi dannosi consegnati e invia gli indicatori a Microsoft quando utile.
7. Ripristina file, librerie o flussi modificati soltanto dopo aver definito il periodo corretto e l'impatto sull'organizzazione.
8. Revoca ancora le sessioni e controlla che le modifiche dannose non ritornino.

Completa quando: ogni meccanismo di persistenza noto è rimosso, le credenziali sono pulite, i contenuti dannosi sono corretti e i controlli successivi non mostrano ricomparse.

Per un solo file mancante o sovrascritto, usa prima la guida al recupero dei file OneDrive. Verifica proprietario, cronologia disponibile e danni in corso prima di un ripristino esteso; può annullare anche modifiche successive legittime.

Riduci la possibilità che accada di nuovo

Obiettivo: correggere la debolezza che ha permesso l'incidente e rendere visibili più rapidamente comportamenti simili.

1. Richiedi autenticazione resistente al phishing per amministratori e utenti ad alto rischio, per esempio passkey o chiavi FIDO2.
2. Rivedi Accesso condizionale, posizioni attendibili, applicazioni legacy e copertura MFA.
3. Limita il consenso utente alle applicazioni e crea un processo di approvazione amministrativa.
4. Blocca l'inoltro automatico esterno quando non è richiesto e monitora nuove regole e deleghe.
5. Riduci ruoli permanenti e privilegi eccessivi. Usa accesso temporaneo e approvato quando possibile.
6. Aggiungi rilevamenti per nuove MFA, consensi OAuth, accessi rischiosi, forwarding, regole e invii anomali.
7. Spiega all'utente il segnale iniziale con un esempio concreto e indica come segnalarlo subito in futuro.

Esempio semplice: se l'attacco è iniziato da una richiesta MFA approvata per errore, non fermarti alla formazione. Introduci anche un metodo resistente al phishing e una policy che riduca le approvazioni ambigue.

Completa quando: ogni causa o lacuna importante ha una correzione applicata oppure un'attività assegnata con proprietario e scadenza.

Conserva una traccia verificabile dell'incidente

Obiettivo: permettere a un altro amministratore di capire cosa è stato osservato, quando è stato raccolto e quali azioni sono state eseguite.

1. Conserva i file originali senza modificarli. Esegui l'analisi su copie.
2. Usa UTC per collegare eventi provenienti da Entra, Exchange, Purview, Defender e dispositivi.
3. Registra le query, i filtri e l'intervallo usati per produrre ogni esportazione.
4. Acquisisci lo stato prima di rimuovere regole, inoltri, metodi MFA, deleghe o consensi.
5. Limita l'accesso alle evidenze e applica la politica di conservazione dell'organizzazione.

Completa quando: ogni conclusione importante può essere collegata a un'evidenza, una fonte, un intervallo temporale e una persona responsabile.

Assegna proprietari, escalation e criteri di chiusura

Obiettivo: evitare decisioni senza proprietario e chiudere il caso soltanto quando accesso, impatto e ripristino sono stati verificati.

Criteri di chiusura

1. Accesso bloccato durante l'incidente, sessioni revocate e credenziali ruotate.
2. Metodi MFA approvati ripristinati e metodi sconosciuti rimossi.
3. Ruoli, gruppi, regole, inoltri, deleghe, app e consensi non autorizzati rimossi.
4. Dispositivi interessati analizzati, isolati o ricostruiti quando necessario.
5. Impatto su posta, file, applicazioni, dati e privilegi definito.
6. Causa principale o ipotesi meglio supportata registrata.
7. Utente o proprietario del servizio ha verificato il normale funzionamento.
8. Monitoraggio pulito per il periodo stabilito dall'organizzazione.
9. Evidenze, azioni, decisioni e notifiche completate.
10. Miglioramenti successivi assegnati con proprietario e scadenza.
11. Responsabile dell'incidente ha approvato esplicitamente la chiusura.

Completa quando: il responsabile dell'incidente conferma che tutti i criteri di chiusura applicabili sono soddisfatti e ogni attività residua ha un proprietario.