Comprendere i casi reali di phishing col DMARC in Microsoft 365

Il protocollo DMARC permette di autenticare le fonti di spedizione di un dominio di posta elettronica. Purtroppo solo 1/4 delle aziende più grandi del pianeta ha configurato correttamente questo aspetto e in Italia la situazione è drammaticamente peggiore. Dato che il 75% degli attacchi informatici partono da una mail è fondamentale comprendere come mettere al sicuro il nostro dominio di posta e come assicurarsi che i nostri partner facciano altrettanto. Per capire come vengono interpretate le email che riceviamo entreremo nel merito del campo Authentication-Results dell’Header di posta elettronica processato da Exchange Online in Microsoft365.

SPF, DKIM e DMARC, questi sconosciuti

Ricordo che, all’inizio degli anni 2000, cominciavano a diffondersi le prime offerte delle linee internet casalinghe in tecnologia ADSL e Telecom Italia l’aveva chiamata BBB (Broad-Band Box). Ne vendettero poche e solo ai nerd come me che ne capirono il messaggio. Appena la chiamarono Alice e ci misero una bella fanciulla in pubblicità, esplosero le richieste.
Analogamente, se invece di SPF, DKIM e DMARC li avessimo chiamati ALICE, EVELYN o DOROTHY magari quale informatico in più avrebbe approfondito. La spiegazione dei protocolli è già stata affrontata in questo articolo ed ora adiamo a vedere come Exchange Online Protection interpreta questi protocolli decidendo come trattare la mail in ingresso. Le interpretazioni che vedremo sono indipendenti dalla licenza perché tutte le sottoscrizioni eseguiranno esattamente le stesse azioni con le medesime logiche.

L’header di una email

Tutte le email che inviamo o riceviamo sono divise in due parti, il body e l’header. Il body è il corpo del messaggio, quello che noi leggiamo o scriviamo, mentre l’header è l’intestazione cioè tutte le informazioni a corredo del corpo del messaggio che determinano le logiche di invio e consegna del messaggio. Tali preziosissime informazioni sono perlopiù nascoste dalle applicazioni di posta elettronica in quanto sono di difficile interpretazione. Ogni email ricevuta ha un header da poter guardare ma ogni applicazione ha il suo metodo per estrarlo e visualizzarlo.

Trovare l’header di una email: Gmail – OutlookThunderbird

Appena compreso dove poterlo leggere è meglio utilizzare uno strumento di interpretazione che lo renda facilmente comprensibile a noi umani. Il sito ufficiale Microsoft è comodo ma indichiamo anche la variante MXToolbox che evidenzia molto bene le logiche DMARC.

Analizzare l’header: MicrosoftMXToolbox

Grazie a questi siti potrete facilmente reperire tantissime utili informazioni, perfino sui sistemi di posta del mittente, ma noi ci concentreremo sul solo campo Authentication-Results. Questo campo viene compilato similmente da tutti i provider di posta elettronica riceventi ma Microsoft inserisce alcune preziose informazioni in più per gestire le logiche DMARC anche se il dominio mittente non implementa esplicitamente questo protocollo. In questo modo sarete in grado di capire come varia il paramentro SCL (Spam Confidence Level) che determina il grado di affidabilità di una mail ricevuta (1 = email buona, 9 = email sicuramente spam).

Le informazioni dell’Authentication-Results

  • spf= Il risultato della verifica del protocollo SPF rispetto al dominio di envelope, il Mail-From.
  • smtp.mailfrom= Il dominio sul quale viene verificato il record SPF.
  • dkim= Il risultato della verifica della firma DKIM rispetto al dominio dichiarato.
  • header.d= Il dominio dichiarato sul quale viene verificata la firma DKIM.
  • dmarc= Il risultato della verifica del protocollo DMARC rispetto alle verifiche SPF e DKIM unite al dominio From.
  • action= L’azione comandata dal record DMARC del dominio di posta From a seguito delle verifiche effettuate in precedenza.
  • header.from= Il dominio sul quale viene verificato il record DMARC e che comanda le azioni di rigetto in caso entrambi i protocolli SPF e DKIM non siano soddisfatti.
  • compauth= L’azione di verifica del record SPF e DKIM con l’allineamento del dominio From anche se il dominio mittente non ha implementato DMARC, viene eseguita solo dai server Exchange Online di Microsoft.
  • reason= La ragione dopo l’azione precedente codificata da Microsoft.

Ulteriori dettagli qui.

Analisi dei casi reali di header Authentication-Results

spf=pass (sender IP is 198.21.0.135) smtp.mailfrom=sendgrid.net; dkim=pass (signature was verified) header.d=sendgrid.net; dmarc=fail action=none header.from=mail.com; compauth=fail reason=001

La mail parte veramente da sendgrid perchè viene firmata e autenticata dal provider di spedizioni massive (spf=pass e dkim=pass) però invia a nome del dominio mail.com che ha la policy del record DMARC p=none quindi, nonostante il controllo DMARC fallisca, non indica di rigettare le mail fasulle. Microsoft rileva comunque il disallineamento del dominio (sendgrid.net diverso da mail.com) in quanto compauth=fail quindi alza SCL a 9 e mette la mail in quarantena.
In questo caso è probabile che sia stato forzato un account Sendgrid precedentemente creato da mail.com e venga usato per spedire mail di phishing. Mail.com dovrebbe adottare una regola p=reject in DMARC.

spf=fail (sender IP is 200.49.169.214) smtp.mailfrom=wetransfer.com; dkim=none (message not signed) header.d=none; dmarc=fail action=oreject header.from=wetransfer.com; compauth=fail reason=000

La mail è fintissima, cerca di impersonificare il dominio wetransfer.com ma con il fallimento di SPF e la mancanza del DKIM entra in gioco il DMARC che, correttamente configurato con policy p=reject, lo evidenzia con action=oreject. Anche Microsoft lo interpreta allo stesso modo con compauth=fail. Tutto funziona bene e la mail è andata in quarantena per il semplice fatto che Microsoft NON rigetta le email che falliscono il DMARC con p=reject, le tratta come se la policy fosse p=quarantine (by design). Nel campo dell’header Received-SPF è possibile capire anche chi manda questa mail fraudolenta.

spf=pass (sender IP is 140.86.230.152) smtp.mailfrom=info.poste.it; dkim=fail (no key for signature) header.d=info.poste.it; dmarc=bestguesspass action=none header.from=info.poste.it; compauth=pass reason=109

La mail parte da un server legittimo di poste.it (usando un sottodominio) in quanto spf=pass ma poi la firma DKIM fallisce perchè non riesce a reperire il selettore per la verifica (errata configurazione). Poco male perchè basta il controllo SPF per renderla buona nonostante non esista il record DMARC. In questo caso Microsoft lo capisce e classifica il dmarc=bestguesspass cioè dice “anche se il dominio mittente non ha il record DMARC ha il protocollo SPF verificato quindi è come se ce l’avesse”. Attenzione però che il dominio poste.it sarebbe facilmente impersonificabile.

spf=softfail (sender IP is 79.60.226.174) smtp.mailfrom=netsearch.org; dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=agenziariscossione.gov.it; compauth=fail reason=001

La mail parte con un dominio SPF netsearch.org (che ha perfino il softfail nel record SPF) impersonificando l’agenzia delle entrate. Agenziariscossione.gov.it non ha il record DMARC quindi nessuno rifiuta la mail. Ma Microsoft capisce la falsità della mail verificando comunque le logiche DMARC col compauth=fail e mette la mail in quarantena. La nostra Agenzia delle Entrate dovrebbe implementare il DMARC per avere certezza che tutti rigettino queste email fasulle mandate a suo nome.

Conclusioni

Il protocollo DMARC è fondamentale per proteggere l’uso fraudolento del proprio dominio di posta che è, a tutti gli effetti, un asset di valore aziendale. Usare Exchange Online come ambiente di posta elettronica permette di gestire le mail in ricezione da tutti i mittenti come se avessero implementato il DMARC. Questo però non garantisce che le nostre email siano “autenticate” quindi assicuratevi di aver implementato nei domini di posta aziendali il DKIM ed il DMARC. Anche sui domini che non usate per spedire posta, sono proprio quelli i più usati per gli attacchi di phishing.