Analisi del phishing

Questo articolo fornisce indicazioni sull'identificazione e l'analisi degli attacchi di phishing all'interno dell'organizzazione. Le istruzioni dettagliate consentono di eseguire l'azione correttiva necessaria per proteggere le informazioni e ridurre al minimo i rischi aggiuntivi.

In questo articolo sono contenute le sezioni seguenti:

• Prerequisiti: copre i requisiti specifici che è necessario completare prima di avviare l'indagine. Ad esempio, la registrazione che deve essere attivata, i ruoli e le autorizzazioni necessarie, tra le altre.
• Flusso di lavoro: mostra il flusso logico da seguire per eseguire questa indagine.
• Elenco di controllo: contiene un elenco di attività per ognuno dei passaggi del grafico di flusso. Questo elenco di controllo può essere utile in ambienti altamente regolamentati per verificare ciò che hai completato o come controllo di qualità per te stesso.
• Passaggi di indagine: include una guida dettagliata per questa indagine specifica.

Prerequisiti

Di seguito sono riportate le impostazioni e le configurazioni generali che è necessario completare prima di procedere con l'analisi del phishing.

Dettagli account

Prima di procedere con l'indagine, è consigliabile avere il nome utente, il nome dell'entità utente (UPN) o l'indirizzo di posta elettronica dell'account sospetto compromesso.

Requisiti di base di Microsoft 365

Verificare le impostazioni di controllo

Verificare che il controllo delle cassette postali attivato per impostazione predefinita sia attivato eseguendo il comando seguente in PowerShell di Exchange Online:

Get-OrganizationConfig | Format-List AuditDisabled

Il valore False indica che il controllo delle cassette postali è abilitato per tutte le cassette postali dell'organizzazione, indipendentemente dal valore della proprietà AuditEnabled nelle singole cassette postali. Per altre informazioni, vedere Verificare che il controllo delle cassette postali attivato per impostazione predefinita sia attivato.

Traccia dei messaggi

I log di traccia dei messaggi sono componenti preziosi che consentono di trovare l'origine originale del messaggio e i destinatari previsti. È possibile usare la funzionalità di traccia dei messaggi nell'interfaccia di amministrazione di Exchange all'indirizzo https://admin.exchange.microsoft.com/#/messagetrace o con il cmdlet Get-MessageTrace in PowerShell di Exchange Online.

Nota

La traccia dei messaggi è disponibile anche nel portale di Microsoft Defender in https://security.microsoft.comEmail &collaboration>Exchange message trace, ma questo è solo un collegamento pass-through alla traccia dei messaggi nell'interfaccia di amministrazione di Exchange.

Diversi componenti della funzionalità di traccia dei messaggi sono autoesplicativi, ma Message-ID è un identificatore univoco per un messaggio di posta elettronica e richiede una conoscenza approfondita. Per ottenere l'ID messaggio per un messaggio di posta elettronica di interesse, è necessario esaminare le intestazioni di posta elettronica non elaborate.

Ricerca log di controllo

Si esegue una ricerca nel log di controllo unificato per visualizzare tutte le attività dell'utente e dell'amministratore nell'organizzazione di Microsoft 365.

I log di accesso e/o i log di controllo vengono esportati in un sistema esterno?

Poiché la maggior parte dei dati di accesso e controllo di Microsoft Entra ID verrà sovrascritta dopo 30 o 90 giorni, è consigliabile usare Sentinel, Monitoraggio di Azure o un sistema SIEM (Security Information and Event Management) esterno.

Ruoli e autorizzazioni necessari

Autorizzazioni in Microsoft Entra ID

È consigliabile che l'account che esegue l'indagine sia almeno un lettore di sicurezza.

Autorizzazioni in Microsoft 365

Il ruolo Con autorizzazioni di lettura per la sicurezza nel portale di Microsoft Defender o nel Portale di conformità di Microsoft Purview deve concedere autorizzazioni sufficienti per eseguire ricerche nei log pertinenti.

Se non si è certi del ruolo da usare, vedere Trovare le autorizzazioni necessarie per eseguire qualsiasi cmdlet di Exchange.

Microsoft Defender for Endpoint

Se si dispone di Microsoft Defender per endpoint (MDE), è consigliabile usarlo per questo flusso. Per altre informazioni, vedere Affrontare il phishing con la condivisione dei segnali e l'apprendimento automatico.

Requisiti di sistema

Requisiti hardware

Il sistema deve essere in grado di eseguire PowerShell.

Requisiti software

Per l'analisi dell'ambiente cloud sono necessari i moduli di PowerShell seguenti:

• Modulo azure AD PowerShell per Graph. Per istruzioni sull'installazione, vedere Installare Azure Active Directory PowerShell per Graph.

  Se sono necessari cmdlet meno recenti nel modulo di Azure AD MSOnline (v1), vedere Microsoft Entra ID (MSOnline).

• Modulo PowerShell di Exchange Online: per istruzioni sull'installazione, vedere Installare e gestire il modulo PowerShell di Exchange Online.

• Modulo PowerShell per la risposta agli eventi imprevisti di Microsoft Entra: per istruzioni sull'installazione, vedere Modulo PowerShell per la risposta agli eventi imprevisti di Microsoft Entra

Workflow

! [Flusso di lavoro di analisi del phishing]

È anche possibile:

• Scaricare i flussi di lavoro del playbook di phishing e di risposta agli eventi imprevisti come PDF.
• Scaricare i flussi di lavoro del playbook di phishing e di risposta agli eventi imprevisti come file di Visio.

Elenco di controllo

Questo elenco di controllo consente di valutare il processo di indagine e verificare se sono stati completati tutti i passaggi durante l'indagine:

	Esaminare la posta elettronica iniziale di phishing
	Ottenere l'elenco degli utenti che hanno ricevuto questo messaggio di posta elettronica
	Ottenere le date più recenti quando l'utente ha avuto accesso alla cassetta postale
	L'accesso delegato è configurato nella cassetta postale?
	Sono configurate regole di inoltro nella cassetta postale?
	Esaminare le regole del flusso di posta di Exchange (regole di trasporto)
	Trovare i messaggi di posta elettronica
	L'utente ha letto o aperto il messaggio di posta elettronica?
	Chi altro ha ricevuto lo stesso messaggio di posta elettronica?
	Il messaggio di posta elettronica contiene un allegato?
	C'era un payload nell'allegato?
	Controllare l'intestazione del messaggio di posta elettronica per l'origine vera del mittente
	Verificare gli indirizzi IP per utenti malintenzionati/campagne
	L'utente ha selezionato i collegamenti nel messaggio di posta elettronica?
	In quale endpoint è stato aperto il messaggio di posta elettronica?
	Il payload dell'allegato è stato eseguito?
	L'INDIRIZZO IP o l'URL di destinazione è stato toccato o aperto?
	Codice dannoso eseguito?
	Quali accessi si sono verificati con l'account per lo scenario federato?
	Quali accessi si sono verificati con l'account per lo scenario gestito?
	Esaminare l'indirizzo IP di origine
	Esaminare l'ID dispositivo trovato
	Analizzare ogni ID app

È anche possibile scaricare gli elenchi di controllo del playbook di phishing e altri eventi imprevisti come file di Excel.

Procedura di indagine

Per questa indagine, si presuppone che tu abbia un messaggio di posta elettronica di phishing di esempio o parti di esso come l'indirizzo del mittente, l'oggetto del messaggio o parti del messaggio per avviare l'indagine. Assicurarsi inoltre di aver completato/abilitato tutte le impostazioni come consigliato nella sezione Prerequisiti .

Questo playbook viene creato con l'intenzione che non tutti i clienti Microsoft e i loro team di indagine abbiano la suite di licenze Microsoft 365 E5 o Microsoft Entra ID P2 disponibile o configurata nel tenant in corso di indagine. Verranno tuttavia evidenziate altre funzionalità di automazione quando appropriato.

Ottenere l'elenco di utenti/identità che hanno ricevuto il messaggio di posta elettronica

Come primo passaggio, è necessario ottenere un elenco di utenti/identità che hanno ricevuto il messaggio di posta elettronica di phishing. L'obiettivo di questo passaggio consiste nel registrare un elenco di potenziali utenti/identità che verranno usati successivamente per scorrere per altri passaggi di indagine. Fare riferimento alla sezione Flusso di lavoro per un diagramma di flusso generale dei passaggi da seguire durante questa indagine.

In questo playbook non vengono fornite raccomandazioni su come si vuole registrare questo elenco di potenziali utenti/identità. A seconda delle dimensioni dell'indagine, è possibile usare un libro di Excel, un file CSV o anche un database per indagini più grandi. Esistono diversi modi per ottenere l'elenco di identità in un determinato tenant e di seguito sono riportati alcuni esempi.

Creare una ricerca contenuto nel Portale di conformità di Microsoft Purview

Usare gli indicatori raccolti per creare ed eseguire una ricerca contenuto. Per istruzioni, vedere Creare una ricerca di contenuto.

Per un elenco completo delle proprietà di posta elettronica ricercabili, vedere proprietà di posta elettronica ricercabili.

L'esempio seguente restituisce i messaggi ricevuti dagli utenti tra il 13 aprile 2022 e il 14 aprile 2022 e che contengono le parole "action" e "required" nella riga dell'oggetto:

(Received:4/13/2022..4/14/2022) AND (Subject:'Action required')

La query di esempio seguente restituisce i messaggi inviati da chatsuwloginsset12345@outlook.com e che contengono la frase esatta "Aggiornare le informazioni sull'account" nella riga dell'oggetto.

(From:chatsuwloginsset12345@outlook.com) AND (Subject:"Update your account information")

Per altre informazioni, vedere come cercare ed eliminare messaggi nell'organizzazione.

Usare il cmdlet Search-Mailbox in PowerShell di Exchange Online

È anche possibile usare il cmdlet Search-Mailbox in PowerShell di Exchange Online per eseguire una query specifica su una cassetta postale di destinazione di interesse e copiare i risultati in una cassetta postale di destinazione non correlata.

La query di esempio seguente cerca nella cassetta postale di Jane Smith un messaggio di posta elettronica contenente la frase Invoice nell'oggetto e copia i risultati in IRMailbox in una cartella denominata "Indagine".

Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full

In questo comando di esempio la query cerca in tutte le cassette postali del tenant un messaggio di posta elettronica contenente la frase "InvoiceUrgent" nell'oggetto e copia i risultati in IRMailbox in una cartella denominata "Indagine".

Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Search-Mailbox.

L'accesso delegato è configurato nella cassetta postale?

Usare lo script seguente per verificare se l'accesso delegato è configurato nella cassetta postale: https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/DumpDelegatesandForwardingRules.ps1.

Per creare questo report, eseguire uno script di PowerShell di piccole dimensioni che ottiene un elenco di tutti gli utenti. Usare quindi il cmdlet Get-MailboxPermission per creare un file CSV di tutti i delegati della cassetta postale nel tenancy.

Cercare nomi insoliti o concessioni di autorizzazioni. Se viene visualizzato qualcosa di insolito, contattare il proprietario della cassetta postale per verificare se è legittimo.

Sono configurate regole di inoltro per la cassetta postale?

È necessario controllare ogni cassetta postale identificata per l'inoltro delle cassette postali (noto anche come inoltro SMTP) o regole posta in arrivo che inoltrano messaggi di posta elettronica a destinatari esterni (in genere, regole della posta in arrivo appena create).

• Per controllare tutte le cassette postali per l'inoltro delle cassette postali, eseguire il comando seguente in PowerShell per Exchange Online:

  Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited | Format-Table -Auto MicrosoftOnlineServicesID,ForwardingSmtpAddress,DeliverToMailboxAndForward | Export-csv C:\Temp\Forwarding.csv -NoTypeInformation
  

• Per verificare la presenza di regole posta in arrivo create nelle cassette postali tra le date specificate, eseguire il comando seguente in PowerShell per Exchange Online:

  Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -ResultSize 5000 -RecordType exchangeadmin -Operations New-InboxRule | Export-csv NoTypeInformation -Path c:\temp\Inboxrulesoutput.csv
  

• È anche possibile usare il report Messaggi inoltrati automaticamente nell'interfaccia di amministrazione di Exchange.You can also use the Auto-forwarded messages report in the Exchange admin center (EAC). Per istruzioni, vedere Report Messaggi inoltrati automaticamente in Exchange Online.

  Note:

  • Cercare posizioni di destinazione insolite o qualsiasi tipo di indirizzamento esterno.
  • Cercare regole di inoltro con parole chiave insolite nei criteri, ad esempio tutti i messaggi di posta elettronica con la fattura parola nell'oggetto. Contattare il proprietario della cassetta postale per verificare se è legittimo.

Esaminare le regole posta in arrivo

Verificare la rimozione delle regole posta in arrivo, considerando i timestamp in prossimità dell'indagine. Ad esempio, usare il comando seguente in PowerShell per Exchange Online:

Search-UnifiedAuditLog -StartDate 12/16/2021 -EndDate 03/16/2022 -Operations Remove-InboxRule | Export-CSV NoTypeInformation -Path c:\temp\removedInboxRules.csv

Esaminare le regole del flusso di posta di Exchange (regole di trasporto)

Esistono due modi per ottenere l'elenco delle regole del flusso di posta di Exchange (note anche come regole di trasporto) nell'organizzazione:

1. Nell'interfaccia di amministrazione di Exchange o in PowerShell di Exchange Online. Per istruzioni, vedere Visualizzare o modificare una regola del flusso di posta.
2. Report della regola di trasporto di Exchange nell'interfaccia di amministrazione di Exchange. Per istruzioni, vedere Report delle regole di trasporto di Exchange in Exchange Online.

Cercare nuove regole o regole modificate per reindirizzare la posta a domini esterni. Il numero di regole deve essere noto e relativamente piccolo. È possibile eseguire una ricerca nel log di controllo per determinare chi ha creato la regola e da dove è stata creata. Se vedi qualcosa di insolito, contatta l'autore per determinare se è legittimo.

Ottenere le date più recenti quando l'utente ha avuto accesso alla cassetta postale

Nel Centro sicurezza e conformità Microsoft 365 passare al log di controllo unificato. In Attività nell'elenco a discesa è possibile filtrare in base alle attività delle cassette postali di Exchange.

La possibilità di elencare gli utenti compromessi è disponibile nel Centro sicurezza e conformità di Microsoft 365.

Questo report mostra le attività che potrebbero indicare che una cassetta postale è accessibile in modo illecito. Include messaggi creati o ricevuti, messaggi spostati o eliminati, messaggi copiati o eliminati, messaggi inviati usando l'invio per conto o l'invio come e tutti gli accessi alle cassette postali. I dati includono data, indirizzo IP, utente, attività eseguita, elemento interessato ed eventuali dettagli estesi.

Nota

Per registrare questi dati, è necessario abilitare l'opzione di controllo delle cassette postali.

Il volume dei dati inclusi qui potrebbe essere molto significativo, quindi concentrarsi sulla ricerca sugli utenti che potrebbero avere un impatto elevato se violato. Cercare modelli insoliti, ad esempio orari dispari del giorno o indirizzi IP insoliti, e cercare modelli come volumi elevati di spostamenti, ripuliture o eliminazioni.

L'utente ha letto/aperto il messaggio di posta elettronica?

Ecco due casi principali:

• La cassetta postale è in Exchange Online.
• La cassetta postale si trova in Exchange locale (ibrido di Exchange).

L'utente di Exchange Online ha aperto il messaggio di posta elettronica

Usare il cmdlet Search-Mailbox in PowerShell di Exchange Online per eseguire una query di ricerca specifica su una cassetta postale di destinazione di interesse e copiare i risultati in una cassetta postale di destinazione non correlata.

La query di esempio seguente cerca nella cassetta postale di Janes Smith un messaggio di posta elettronica contenente la frase Invoice nell'oggetto e copia i risultati in IRMailbox in una cartella denominata Investigation.

Search-Mailbox -Identity "Jane Smith" -SearchQuery "Subject:Invoice" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" LogLevel Full

La query di esempio seguente cerca in tutte le cassette postali del tenant un messaggio di posta elettronica contenente la frase InvoiceUrgent nell'oggetto e copia i risultati in IRMailbox in una cartella denominata Investigation.

Get-Mailbox | Search-Mailbox -SearchQuery 'InvoiceUrgent vote' -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

L'utente ha aperto la posta elettronica in Exchange ibrido

Usare il cmdlet Get-MessageTrackingLog per cercare le informazioni sul recapito dei messaggi archiviate nel log di rilevamento dei messaggi. Ecco un esempio:

Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2022 09:00:00" -End "03/15/2022 17:00:00" -Sender "john@contoso.com"

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Get-MessageTrackingLog.

Chi altro ha ricevuto lo stesso messaggio di posta elettronica?

Ecco due casi principali:

• La cassetta postale è in Exchange Online.
• La cassetta postale si trova in Exchange locale (ibrido di Exchange).

Il flusso di lavoro è essenzialmente lo stesso illustrato nella sezione Ottenere l'elenco di utenti/identità che hanno ricevuto il messaggio di posta elettronica in precedenza in questo articolo.

Trovare il messaggio di posta elettronica in Exchange Online

Usare il cmdlet Search-Mailbox per eseguire una query di ricerca specifica su una cassetta postale di destinazione di interesse e copiare i risultati in una cassetta postale di destinazione non correlata.

Questa query di esempio cerca in tutte le cassette postali del tenant un messaggio di posta elettronica contenente l'oggetto InvoiceUrgent nell'oggetto e copia i risultati in IRMailbox in una cartella denominata Investigation.

Get-Mailbox | Search-Mailbox -SearchQuery "Subject:InvoiceUrgent" -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

Trovare il messaggio di posta elettronica in Exchange locale

Usare il cmdlet Get-MessageTrackingLog per cercare le informazioni sul recapito dei messaggi archiviate nel log di rilevamento dei messaggi. Ecco un esempio:

Get-MessageTrackingLog -Server Mailbox01 -Start "03/13/2018 09:00:00" -End "03/15/2018 17:00:00" -MessageSubject "InvoiceUrgent"

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Get-MessageTrackingLog.

Il messaggio di posta elettronica contiene un allegato?

Ecco due casi principali:

• La cassetta postale è in Exchange Online.
• La cassetta postale si trova in Exchange locale (ibrido di Exchange).

Verificare se il messaggio contiene un allegato in Exchange Online

Se la cassetta postale è in Exchange Online, sono disponibili due opzioni:

• Usare il cmdlet classico Search-Mailbox
• Usare il cmdlet New-ComplianceSearch

Usare il cmdlet Search-Mailbox per eseguire una query di ricerca specifica su una cassetta postale di destinazione di interesse e copiare i risultati in una cassetta postale di destinazione non correlata. Ecco un esempio:

Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery attachment:trojan* -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Search-Mailbox.

L'altra opzione consiste nell'usare il cmdlet New-ComplianceSearch . Ecco un esempio:

New-ComplianceSearch -Name "Investigation" -ExchangeLocation "Research Department" -ContentMatchQuery "from:pilar@contoso.com AND hasattachment:true"

Per informazioni dettagliate sulla sintassi e sui parametri, vedere New-ComplianceSearch.

Verificare se il messaggio contiene un allegato in Exchange locale

Nota

In Exchange Server 2013, questa procedura richiede l'aggiornamento cumulativo 12 (CU12) o versione successiva. Per altre informazioni, vedi questo articolo.

Usare il cmdlet Search-Mailbox per cercare le informazioni sul recapito dei messaggi archiviate nel log di rilevamento dei messaggi. Ecco un esempio:

Search-Mailbox -Identity "Jane Smith"-SearchQuery AttachmentNames:attachment_name -TargetMailbox "IRMailbox" -TargetFolder "Investigation" -LogLevel Full

Per informazioni dettagliate sulla sintassi e sui parametri, vedere Search-Mailbox.

C'era un payload nell'allegato?

Cercare potenziali contenuti dannosi nell'allegato. Ad esempio, file PDF, PowerShell offuscato o altri codici di script.

La visualizzazione Visualizza dati per malware di posta elettronica > nel report Stato protezione dalle minacce mostra il numero di messaggi in ingresso e in uscita rilevati come contenenti malware per l'organizzazione. Per altre informazioni, vedere Report sullo stato della protezione dalle minacce: Visualizzare i dati in base al malware della posta elettronica>.

Controllare l'intestazione del messaggio di posta elettronica per l'origine vera del mittente

Molti dei componenti della funzionalità di traccia dei messaggi sono autoesplicativi, ma è necessario comprendere attentamente l'ID messaggio. Message-ID è un identificatore univoco per un messaggio di posta elettronica.

Per ottenere l'ID messaggio per un messaggio di posta elettronica di interesse, è necessario esaminare le intestazioni di posta elettronica non elaborate. Per istruzioni su come eseguire questa operazione in Microsoft Outlook o Outlook sul Web (in precedenza noto come Outlook Web App o OWA), vedere Visualizzare le intestazioni dei messaggi Internet in Outlook

Quando si visualizza un'intestazione di posta elettronica, è consigliabile copiare e incollare le informazioni sull'intestazione in un analizzatore dell'intestazione di posta elettronica fornito da MXToolbox o Azure per la leggibilità.

• Intestazioni Informazioni di routing: le informazioni di routing forniscono la route di un messaggio di posta elettronica durante il trasferimento tra computer.

• Sender Policy Framework (SPF): convalida tramite posta elettronica per impedire o rilevare lo spoofing. Nel record SPF è possibile determinare quali indirizzi IP e domini possono inviare messaggi di posta elettronica per conto del dominio.

• SPF = Pass: il record TXT SPF ha determinato che il mittente può inviare per conto di un dominio.

  • SPF = Neutral
  • SPF = Fail: la configurazione dei criteri determina il risultato dell'INDIRIZZO IP del mittente del messaggio
  • Posta SMTP: verificare se si tratta di un dominio legittimo

  Per altre informazioni su SPF, vedere Come Microsoft 365 usa SPF per impedire lo spoofing

• Valori comuni: ecco una suddivisione delle intestazioni usate e visualizzate più comunemente e dei relativi valori. Si tratta di informazioni preziose ed è possibile usarle nei campi di ricerca in Esplora minacce.

  • Indirizzo mittente
  • Oggetto
  • ID del messaggio
  • Da risolvere
  • Indirizzo del percorso restituito

• Authentication-Results: è possibile trovare il client di posta elettronica autenticato al momento dell'invio del messaggio di posta elettronica. Fornirà l'autenticazione SPF e DKIM.

• IP di origine: l'INDIRIZZO IP originale può essere usato per determinare se l'INDIRIZZO IP è bloccato e ottenere la posizione geografica.

• Livello di attendibilità della posta indesiderata (SCL): determina la probabilità che un messaggio di posta elettronica in arrivo sia posta indesiderata.

  • -1: Ignorare la maggior parte dei filtri di posta indesiderata da un mittente sicuro, un destinatario sicuro o un indirizzo IP sicuro (partner attendibile)
  • 0, 1: Posta indesiderata perché il messaggio è stato analizzato e determinato come pulito
  • 5, 6: Posta indesiderata
  • 7, 8, 9: posta indesiderata con attendibilità elevata

Il record SPF viene archiviato all'interno di un database DNS e viene in bundle con le informazioni di ricerca DNS. È possibile controllare manualmente il record SPF (Sender Policy Framework) per un dominio usando il comando nslookup :

1. Aprire il prompt dei comandi (Avvia > esegui > cmd).

2. Digitare il comando come spazio nslookup -type=txt" e quindi il nome di dominio/host. Ad esempio:

    nslookup -type=txt domainname.com
   

Nota

-all (rifiutarli o fallirli- non recapitare il messaggio di posta elettronica se qualcosa non corrisponde), questo è consigliato.

Controllare se DKIM è abilitato nei domini personalizzati in Microsoft 365

È necessario pubblicare due record CNAME per ogni dominio che vogliono aggiungere le chiavi di dominio identificate tramite posta elettronica (DKIM). Vedere come usare DKIM per convalidare la posta elettronica in uscita inviata dal dominio personalizzato.

Verificare la presenza di autenticazione dei messaggi basata su dominio, creazione di report e conformità (DMARC)

È possibile usare questa funzionalità per convalidare la posta elettronica in uscita in Microsoft 365.

Verificare gli indirizzi IP per utenti malintenzionati/campagne

Per verificare o analizzare gli indirizzi IP identificati dai passaggi precedenti dell'indagine, è possibile usare una di queste opzioni:

• Virustotal
• Microsoft Defender for Endpoint
• Origini pubbliche:
  • Ipinfo.io - È disponibile un'opzione gratuita per ottenere la posizione geografica
  • Censys.io - Offre un'opzione gratuita per ottenere informazioni su ciò che le analisi passive di Internet conoscono
  • AbuseIPDB.com - Offre un'opzione gratuita che fornisce una georilevazione
  • Chiedi a Bing e Google - Cerca nell'indirizzo IP

Reputazione URL

Puoi usare qualsiasi dispositivo Windows 10 e browser Microsoft Edge che sfrutta la tecnologia SmartScreen .

Ecco alcuni esempi di reputazione di URL di terze parti

• Trend Micro Site Cassaforte ty Check
• Rapporto sulla trasparenza di Google
• Talos Intelligency

Durante l'analisi degli indirizzi IP e degli URL, cercare e correlare gli indirizzi IP agli indicatori di compromissione (IOC) o altri indicatori, a seconda dell'output o dei risultati e aggiungerli a un elenco di origini dall'avversario.

L'utente ha fatto clic sui collegamenti nel messaggio di posta elettronica?

Se l'utente ha fatto clic sul collegamento nel messaggio di posta elettronica (a scopo o meno), questa azione in genere porta a una nuova creazione del processo nel dispositivo stesso. A seconda del dispositivo eseguito, è necessario eseguire indagini specifiche del dispositivo. Ad esempio, Windows vs Android e iOS. In questo articolo è stato descritto un approccio generale insieme ad alcuni dettagli per i dispositivi basati su Windows. Se si usa Microsoft Defender per endpoint (MDE), è anche possibile sfruttarlo per iOS e presto Android.

È possibile analizzare questi eventi usando Microsoft Defender per endpoint.

1. Log VPN/proxy A seconda del fornitore delle soluzioni proxy e VPN, è necessario controllare i log pertinenti. Idealmente si stanno inoltrando gli eventi al siem o a Microsoft Sentinel.

2. Usando Microsoft Defender per endpoint Questo è lo scenario migliore, perché è possibile usare l'intelligence sulle minacce e l'analisi automatizzata per facilitare l'analisi. Per altri dettagli, vedere come analizzare gli avvisi in Microsoft Defender per endpoint.

   L'albero del processo di avviso accetta la valutazione e l'analisi degli avvisi al livello successivo, visualizzando gli avvisi aggregati e le prove circostanti che si sono verificati nello stesso contesto di esecuzione e nello stesso periodo di tempo.

3. Dispositivi client basati su Windows Assicurarsi di aver abilitato l'opzione Eventi di creazione processo. Idealmente, è consigliabile abilitare anche gli eventi di traccia della riga di comando.

   Nei client Windows, che dispongono degli eventi di controllo indicati in precedenza abilitati prima dell'indagine, è possibile controllare l'evento 4688 e determinare l'ora in cui il messaggio di posta elettronica è stato recapitato all'utente:

   

   

In quale endpoint è stato aperto il messaggio di posta elettronica?

Le attività seguenti sono simili al passaggio precedente dell'indagine: l'utente ha fatto clic sui collegamenti nel messaggio di posta elettronica?

Il payload collegato è stato eseguito?

Le attività seguenti sono simili al passaggio precedente dell'indagine: l'utente ha fatto clic sui collegamenti nel messaggio di posta elettronica?

L'INDIRIZZO IP/URL di destinazione è stato toccato o aperto?

Le attività seguenti sono simili al passaggio precedente dell'indagine: l'utente ha fatto clic sui collegamenti nel messaggio di posta elettronica?

Codice dannoso eseguito?

Le attività seguenti sono simili al passaggio precedente dell'indagine: l'utente ha fatto clic sui collegamenti nel messaggio di posta elettronica?

Quali accessi si sono verificati con l'account?

Controllare i vari accessi che si sono verificati con l'account.

Scenario federato

Le impostazioni e gli eventi del log di controllo differiscono in base al livello del sistema operativo e alla versione del server Active Directory Federation Services (ADFS).

Per le diverse versioni del server, vedere le sezioni seguenti.

Server 2012 R2

Per impostazione predefinita, gli eventi di sicurezza non vengono controllati in Server 2012 R2. È necessario abilitare questa funzionalità in ogni server ADFS nella farm. Nella console di gestione di ADFS e selezionare Modifica proprietà servizio federativo.

È anche necessario abilitare i criteri di controllo del sistema operativo.

Aprire il prompt dei comandi ed eseguire il comando seguente come amministratore.

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

Per altre informazioni, vedere come configurare i server ADFS per la risoluzione dei problemi.

È anche possibile scaricare i moduli powerShell di ADFS da:

• GitHub
• Microsoft scriptcenter

Server 2016 e versioni successive

Per impostazione predefinita, IN ADFS in Windows Server 2016 è abilitato il controllo di base. Con il controllo di base, gli amministratori possono visualizzare cinque o meno eventi per una singola richiesta. Tuttavia, è possibile aumentare o abbassare il livello di controllo usando questo comando:

Set-AdfsProperties -AuditLevel Verbose

Per altre informazioni, vedere Miglioramenti del controllo ad ADFS in Windows Server.

Se è installato Microsoft Entra Connessione Health, è consigliabile esaminare anche il report Ip rischioso. Gli indirizzi IP client dell'attività di accesso non riusciti vengono aggregati tramite i server proxy dell'applicazione Web. Ogni elemento nel report IP rischioso mostra informazioni aggregate sulle attività di accesso ad AD FS non riuscite che superano la soglia designata.

Per altri dettagli, vedere Report ip rischiosi.

Server 2012 R2

ID evento 342 : "Il nome utente o la password non sono corretti" nei log di amministrazione di ADFS.

Per gli eventi di controllo effettivi, è necessario esaminare i log degli eventi di sicurezza e cercare gli eventi con ID evento 411 per Errore di controllo classico con l'origine come controllo ADFS. Cercare anche l'ID evento 412 in caso di autenticazione riuscita.

ID evento 411 SecurityTokenValidationFailureAudit Token validation failed( Convalida del token 411 - SecurityTokenValidationFailureAudit Token validation failed). Per altri dettagli, vedere l'eccezione interna.

Potrebbe essere necessario correlare l'evento con l'ID evento corrispondente 501.

Server 2016 e versioni successive

Per gli eventi di controllo effettivi, è necessario esaminare i log degli eventi di sicurezza e cercare gli eventi con la ricerca dell'ID evento 1202 per gli eventi di autenticazione riusciti e 1203 per gli errori

Esempio di ID evento1202:

ID evento 1202 FreshCredentialSuccessAudit Il servizio federativo ha convalidato una nuova credenziale. Per informazioni dettagliate, vedere XML.

Esempio per ID evento 1203:

ID evento 1203 FreshCredentialFailureAudit Il servizio federativo non è riuscito a convalidare una nuova credenziale. Per informazioni dettagliate sull'errore, vedere XML.

Per ottenere l'elenco completo dell'ID evento ADFS per livello di sistema operativo, vedere GetADF edizione Standard ventList.

Scenario gestito

Controllare i log di accesso di Microsoft Entra per gli utenti che si stanno esaminando.

• Passare alla schermata di accesso dell'interfaccia di amministrazione di Microsoft Entra >
• Controllare le attività di accesso
• Controllare la funzione di PowerShell in GitHub

Nell'interfaccia di amministrazione di Microsoft Entra passare alla schermata Accessi e aggiungere/modificare il filtro di visualizzazione per l'intervallo di tempo rilevato nei passaggi precedenti dell'indagine, nonché aggiungere il nome utente come filtro, come illustrato in questa immagine.

È anche possibile eseguire ricerche usando l'API Graph. Ad esempio, filtrare in base alle proprietà utente e ottenere lastSignInDate insieme a esso. Cercare un utente specifico per ottenere l'ultima data di accesso per l'utente. Ad esempio, https://graph.microsoft.com/beta/users?$filter=startswith(displayName,'Dhanyah')&$select=displayName,signInActivity

In alternativa, è possibile usare il comando Get-AzureADUserLastSignInActivity di PowerShell per ottenere l'ultima attività di accesso interattiva per l'utente, di destinazione del relativo ID oggetto. In questo esempio l'output viene scritto in un file CSV con data e ora nella directory di esecuzione.

Get-AzureADUserLastSignInActivity -TenantId 536279f6-1234-2567-be2d-61e352b51eef -UserObjectId 69447235-0974-4af6-bfa3-d0e922a92048 -CsvOutput

In alternativa, è possibile usare questo comando dal modulo AzureADIncidentResponse di PowerShell:

Get-AzureADIRSignInDetail -UserId johcast@Contoso.com -TenantId 536279f6-1234-2567-be2d-61e352b51eef -RangeFromDaysAgo 29 -RangeToDaysAgo 3

Analizzare l'indirizzo IP di origine

In base agli indirizzi IP di origine trovati nei log di accesso di Microsoft Entra o nei file di log di ADFS/Federation Server, esaminare ulteriormente per sapere da dove ha avuto origine il traffico.

Utente gestito

Per uno scenario gestito, è consigliabile iniziare a esaminare i log di accesso e filtrare in base all'indirizzo IP di origine:

In alternativa, è possibile usare questo comando dal modulo AzureADIncidentResponse di PowerShell:

Get-AzureADIRSignInDetail -IpAddress 1.2.3.4 -TenantId 536279f6-1234-2567-be2d-61e352b51eef -RangeFromDaysAgo 29 -RangeToDaysAgo 3 -OutGridView

Quando si esamina l'elenco dei risultati, passare alla scheda Informazioni sul dispositivo. A seconda del dispositivo usato, si otterrà un output variabile. Ecco alcuni esempi:

• Esempio 1 - Dispositivo non gestito (BYOD):

  

• Esempio 2 - Dispositivo gestito (aggiunta a Microsoft Entra o join ibrido di Microsoft Entra):

  

Verificare la presenza di DeviceID se presente. È anche necessario cercare il sistema operativo e il browser o la stringa UserAgent .

Registrare CorrelationID, ID richiesta e timestamp. È consigliabile usare CorrelationID e timestamp per correlare i risultati ad altri eventi.

Utente/applicazione federato

Seguire la stessa procedura fornita per lo scenario di accesso federato.

Cercare e registrare DeviceID , OS Level, CorrelationID, RequestID.

Analizzare l'ID dispositivo identificato

Questo passaggio è rilevante solo per i dispositivi noti a Microsoft Entra ID. Ad esempio, dai passaggi precedenti, se sono stati trovati uno o più ID dispositivo potenziali, è possibile esaminare ulteriormente il dispositivo. Cercare e registrare DeviceID e Device Owner.

Analizzare ogni ID app

Il punto di partenza sono i log di accesso e la configurazione dell'app del tenant o della configurazione dei server federativi.

Scenario gestito

Dai dettagli del log di accesso trovati in precedenza, controllare l'ID applicazione nella scheda Informazioni di base:

Si notino le differenze tra l'applicazione (e l'ID) con la risorsa (e l'ID). L'applicazione è il componente client interessato, mentre la risorsa è il servizio/applicazione in Microsoft Entra ID.

Con questo AppID è ora possibile eseguire ricerche nel tenant. Ecco un esempio:

Get-MgApplication -Filter "AppId eq '30d4cbf1-c561-454e-bf01-528cd5eafd58'"

Id                                       AppId                                    DisplayName

3af6dc4e-b0e5-45ec-8272-56f3f3f875ad     30d4cbf1-c561-454e-bf01-528cd5eafd58     Claims X-Ray

Con queste informazioni, è possibile eseguire ricerche nel portale applicazioni aziendali. Passare a Tutte le applicazioni e cercare l'ID app specifico.

Playbook aggiuntivi per la risposta agli eventi imprevisti

Esaminare le linee guida per identificare e analizzare questi tipi aggiuntivi di attacchi:

• Password spraying
• Consenso dell'app
• Approccio ransomware e procedure consigliate per il team di risposta agli eventi imprevisti Microsoft

Risorse di risposta agli eventi imprevisti

• Panoramica dei prodotti e delle risorse per la sicurezza Microsoft per analisti esperti e nuovi ruoli
• Pianificazione del Centro operazioni di sicurezza (SOC)
• Risposta agli eventi imprevisti di Microsoft Defender XDR
• Microsoft Defender per il cloud (Azure)
• Risposta agli eventi imprevisti di Microsoft Sentinel
• Il team di risposta agli eventi imprevisti Microsoft condivide le procedure consigliate per i team e i responsabili della sicurezza
• Le guide alla risposta agli eventi imprevisti Microsoft aiutano i team di sicurezza ad analizzare le attività sospette