10 falle dei filtri email: i segnali sottili che il tuo gateway ignora

⚡TL;DR

• I gateway email bloccano lo spam evidente ma non rilevano gli attacchi sofisticati che sfruttano falle sottili nelle intestazioni
• 10 indicatori precisi nelle intestazioni tradiscono le email malevole: disallineamento di busta, DKIM di terze parti, Reply-To divergente, catena Received anomala e altri sei segnali tecnici
• Ogni indicatore viene decostruito dal punto di vista dell'attaccante (come lo sfrutta) e del difensore (come rilevarlo)
• L'analisi delle intestazioni dopo il gateway è l'ultima linea di difesa per l'1% di email che supera tutti i filtri

Il tuo gateway email mostra un tasso di blocco del 99,5%. Il rapporto mensile è rassicurante, le dashboard sono verdi e il tuo team di sicurezza passa all'argomento successivo. Il problema si nasconde nel restante 0,5%. Su un volume di 200 000 email mensili, questo rappresenta 1 000 messaggi non filtrati. Tra questi, basta una sola email di spear-phishing diretta al dipendente giusto per compromettere un account privilegiato, esfiltrare dati o innescare un ransomware. Il costo medio di una violazione iniziata da phishing raggiunge 4,8 milioni di dollari (IBM, Cost of a Data Breach 2025), e il tempo medio per rilevare una compromissione da phishing è di 207 giorni (IBM, 2025). Secondo il rapporto Verizon DBIR 2025, il tempo mediano tra la ricezione di un'email di phishing e il primo clic è di 21 secondi. I tuoi utenti non riflettono: reagiscono.

I gateway di sicurezza email (Secure Email Gateways, SEG) come Proofpoint, Mimecast, Barracuda o Microsoft Defender for Office 365 analizzano il contenuto, la reputazione IP, le firme conosciute e le euristiche comportamentali. Ma condividono un punto cieco comune: i segnali sottili nelle intestazioni SMTP e MIME che gli attaccanti sofisticati manipolano per superare i filtri senza attivare alcun allarme. I numeri sono chiari: i gateway falliscono sul 30-50% delle minacce avanzate, e il volume di email malevole che eludono i SEG è aumentato del 105% in un anno, ossia un'email malevola ogni 19 secondi che supera i filtri (Cofense, Annual State of Email Security 2026). Non sorprende che il 91% dei responsabili sicurezza si dichiari frustrato dalle prestazioni del proprio SEG (Egress, Email Security Risk Report 2024). Non è un problema teorico. Nel 2025, il gruppo Tycoon2FA ha sfruttato falle di routing MX e autenticazione email per generare 13 milioni di email malevole in un solo mese, eludendo i gateway di migliaia di organizzazioni. In totale, il 78% delle organizzazioni ha subito almeno una violazione email negli ultimi 12 mesi (Barracuda, 2025).

Questo articolo analizza 10 indicatori precisi nelle intestazioni email che la maggior parte dei gateway ignora o sottovaluta. Per ogni indicatore, viene dettagliata la prospettiva dell'attaccante (come lo sfrutta) e quella del difensore (come rilevarlo), con esempi concreti di intestazioni. Se sei un ingegnere di sicurezza, analista SOC, amministratore email o CISO, questi 10 segnali dovrebbero fare parte della tua griglia di analisi post-gateway.

Perché i filtri email non bastano

Cosa verificano i gateway (e cosa ignorano)

I gateway email moderni si basano su diversi livelli di filtraggio. La reputazione IP verifica se l'indirizzo del server mittente figura nelle liste nere (Spamhaus, Barracuda, SpamCop). L'analisi del contenuto cerca parole chiave sospette, URL malevoli e allegati pericolosi. Le firme anti-malware confrontano i file con database di definizioni conosciute. Le euristiche comportamentali rilevano schemi di invio di massa e anomalie statistiche.

Questa architettura funziona contro lo spam di massa e le campagne di phishing generiche. Un server con un IP in lista nera, un'email con "Clicca qui per recuperare il tuo premio" e un allegato .exe vengono bloccati prima di raggiungere la casella di posta. Il tasso di blocco del 99% è reale per questo tipo di minacce.

Ma gli attaccanti che prendono di mira la tua organizzazione non fanno niente di tutto questo. Inviano da IP puliti (affittati su ESP legittimi), scrivono messaggi credibili e manipolano le intestazioni SMTP perché il messaggio assomigli a un'email legittima. Dato notevole: l'82,6% delle email di phishing analizzate usa ormai una forma di IA per la redazione (KnowBe4, Phishing Threat Trends 2025), e il tasso di clic su queste email generate da IA raggiunge il 54%, contro il 12% per le email scritte manualmente (Brightside AI, 2025). Inoltre, il 76,4% degli attacchi di phishing contiene almeno un tratto polimorfico, cioè ogni email inviata è leggermente diversa per sfuggire alle firme statiche (KnowBe4, 2025). Il gateway vede un'email che "supera" tutti i suoi criteri standard e la lascia passare.

Quello che i gateway ignorano in larga misura sono i segnali di coerenza nelle intestazioni. Un'email legittima presenta coerenza interna: il dominio del From corrisponde al dominio del Return-Path e del Message-ID, la firma DKIM copre il dominio corretto, la catena Received è logica e le intestazioni proprietarie della piattaforma di hosting sono presenti. Quando un attaccante falsifica un'email, riproduce le intestazioni visibili (From, Subject, Date) ma lascia incoerenze nelle intestazioni tecniche che solo un esame approfondito rivela. I gateway non effettuano questo esame.

Il paradosso dell'adattamento

Più un filtro è rigoroso, più l'attaccante si adatta. I gruppi di minacce avanzate (APT, operazioni di spear-phishing mirato) testano sistematicamente le loro email contro i gateway del mercato prima di lanciare una campagna. Servizi clandestini offrono "SEG testing": l'attaccante invia la sua email e riceve un rapporto che indica quali gateway la bloccano e quali la lasciano passare. È un processo iterativo. L'attaccante modifica le intestazioni, il contenuto e l'infrastruttura di invio fino a ottenere un tasso di passaggio soddisfacente.

Il risultato: le email che arrivano nella casella di posta dopo il gateway non sono tentativi falliti. Sono i tentativi più riusciti, quelli che sono stati ottimizzati per eludere le tue difese specifiche. È un bias cognitivo frequente nei team di sicurezza: considerare che ciò che supera il gateway sia "probabilmente legittimo". In realtà, è esattamente il contrario. Ciò che supera il gateway dopo un filtraggio rigoroso è potenzialmente più pericoloso dello spam medio, perché è stato progettato per passare.

Questo fenomeno spiega perché gli utenti formati a riconoscere i segni visivi del phishing continuano a cadere nella trappola. Le email che superano il gateway non contengono più errori ortografici, layout approssimativi o URL evidenti. Assomigliano a email legittime perché sono state ottimizzate per questo. L'unica differenza risiede nelle intestazioni tecniche, invisibili per l'utente finale.

L'ultima linea di difesa: l'analisi post-gateway

Ecco perché l'analisi delle intestazioni dopo il filtraggio è critica. I 10 indicatori dettagliati in questo articolo non sostituiscono il gateway: completano il rilevamento esaminando segnali che i filtri automatizzati non verificano o verificano male. Questa analisi può essere manuale (per incidenti individuali), semi-automatizzata (regole di trasporto Exchange/Gmail) o integrata in un SIEM per il rilevamento su larga scala.

I 10 indicatori che il tuo gateway ignora

1. Disallineamento Return-Path / From (disallineamento di busta)

Come lo sfrutta l'attaccante. Il protocollo SMTP separa due identità distinte: il mittente di busta (MAIL FROM, visibile nell'intestazione Return-Path) e il mittente visualizzato (intestazione From). L'attaccante configura il suo server per inviare con un Return-Path che controlla (bounce@attaccante-infra.net) mostrando un From credibile (direction@captaindns.com). La maggior parte dei client email mostra solo il From. Il destinatario vede un'email che sembra provenire dalla direzione, senza sospettare che la busta punti altrove.

Perché i filtri lo ignorano. I gateway verificano SPF sul Return-Path e DKIM sul From, ma pochi confrontano attivamente i due e allertano su un disallineamento. Un SPF pass sul Return-Path e un DKIM pass su un dominio di terze parti sono spesso sufficienti per lasciar passare il messaggio.

Cosa deve verificare il difensore. Confrontare il dominio nel Return-Path con il dominio nel From. Se differiscono senza ragione legittima (mailing list, ESP configurato), è un segnale forte.

Esempio di intestazione:

Return-Path: <bounce-7842@attaccante-infra.net>
From: "Direzione Generale" <direction@captaindns.com>

Il disallineamento è visibile immediatamente: la busta proviene da attaccante-infra.net, il From mostra captaindns.com. Un'email legittima inviata tramite un ESP avrebbe un Return-Path contenente il dominio dell'ESP configurato nel SPF del dominio mittente, non un dominio di terze parti sconosciuto.

Quando il disallineamento è legittimo. È normale che il Return-Path differisca dal From in certi casi: gli ESP (SendGrid, Mailgun, Amazon SES) usano il proprio dominio per il Return-Path per gestire i bounce. Le mailing list riscrivono il Return-Path. La chiave è verificare se il dominio del Return-Path è quello di un servizio conosciuto e configurato nel SPF del dominio del From. Un Return-Path verso un dominio sconosciuto (attaccante-infra.net) associato a un From aziendale (captaindns.com) senza collegamento SPF è un segnale forte.

2. DKIM firmato da un dominio di terze parti (firma delegata)

Come lo sfrutta l'attaccante. L'attaccante crea un account su un ESP legittimo (SendGrid, Mailgun, Amazon SES) e configura DKIM per il proprio dominio. Poi invia un'email con un From falsificato (compta@captaindns.com). Il messaggio porta una firma DKIM valida, ma firmata dal dominio dell'attaccante (d=attaccante-marketing.com), non da captaindns.com. Il gateway vede "dkim=pass" e considera il messaggio autenticato.

Perché i filtri lo ignorano. I gateway verificano che la firma DKIM sia tecnicamente valida (la chiave pubblica corrisponde, l'hash del corpo è corretto). Ma la maggior parte non verifica se il dominio firmatario (d=) corrisponde al dominio del From. Questo è il ruolo dell'allineamento DMARC, e molte organizzazioni non hanno ancora implementato DMARC in modalità rigorosa.

Cosa deve verificare il difensore. Nell'intestazione DKIM-Signature, confrontare il campo d= con il dominio del From. Se non corrispondono, l'email è firmata da terze parti che non hanno autorità sul dominio mostrato.

Esempio di intestazione:

DKIM-Signature: v=1; a=rsa-sha256; d=attaccante-marketing.com;
    s=sel2026; c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Servizio Contabilità" <compta@captaindns.com>

Il d=attaccante-marketing.com non corrisponde al From captaindns.com. La firma è tecnicamente valida ma l'allineamento è rotto.

3. SPF pass ma allineamento DMARC fallito

Come lo sfrutta l'attaccante. L'attaccante invia da un server il cui IP è autorizzato dal SPF di un dominio che controlla (il proprio dominio o un dominio ESP). Il MAIL FROM (busta) usa quel dominio autorizzato, dando un SPF pass. Ma il From (intestazione) mostra il dominio del bersaglio (rh@captaindns.com). SPF passa, DKIM è assente o firmato da un altro dominio, e DMARC fallisce in allineamento. Se il dominio bersaglio ha una policy DMARC p=none, nessuna azione viene intrapresa. E questa falla è massiccia: l'84,2% degli attacchi di phishing analizzati supera i controlli DMARC (Egress, Email Security Risk Report 2024), in gran parte perché il 47% dei domini email non ha alcuna configurazione DMARC (Barracuda, 2025), il 63% degli implementatori resta su p=none (Mailgun/Email on Acid, 2025) e solo il 4% dei domini applica p=reject (Valimail, 2025).

Perché i filtri lo ignorano. Il gateway vede spf=pass nei risultati di autenticazione e attribuisce un punteggio positivo. Il fatto che l'allineamento DMARC fallisca è spesso sottoponderato se la policy è p=none. Il risultato netto: il messaggio supera il filtraggio con un "punteggio di autenticazione accettabile".

Cosa deve verificare il difensore. Nell'intestazione Authentication-Results, cercare la combinazione spf=pass con dmarc=fail. Questa combinazione indica che SPF è passato su un dominio diverso dal From, segnale classico di spoofing.

Esempio di intestazione:

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 198.51.100.42)
        smtp.mailfrom=bounces.attaccante-esp.com;
    dkim=none;
    dmarc=fail (p=none dis=none) header.from=captaindns.com

Lo spf=pass riguarda attaccante-esp.com (busta), non captaindns.com (From). DMARC fallisce perché nessun meccanismo (SPF o DKIM) è allineato con il dominio del From. La policy p=none lascia passare.

4. Reply-To verso un dominio diverso dal From

Come lo sfrutta l'attaccante. L'attaccante falsifica un From credibile (support@captaindns.com) ma inserisce un Reply-To verso un indirizzo che controlla (support-captaindns@protonmail.com o support@captaindns-helpdesk.com). Quando il destinatario risponde, la sua risposta va all'attaccante. È una tecnica terribilmente efficace per il BEC (Business Email Compromise), che ha causato 55,5 miliardi di dollari di perdite cumulate in dieci anni (FBI IC3, 2024). La prima email non contiene né link né allegati, evitando così qualsiasi rilevamento tramite analisi del contenuto.

Perché i filtri lo ignorano. Il Reply-To è un'intestazione informativa, non un meccanismo di autenticazione. I gateway generalmente non confrontano il dominio del Reply-To con quello del From. Un'email senza URL sospetti né allegati, con un SPF pass e un contenuto testuale pulito, supera i filtri senza difficoltà.

Cosa deve verificare il difensore. Confrontare il dominio dell'intestazione Reply-To con quello del From. Un disallineamento verso un dominio gratuito (Gmail, ProtonMail, Outlook.com) o un dominio simile (typosquatting) è un segnale forte di BEC.

Esempio di intestazione:

From: "Jean Dupont - DAF" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Bonifico urgente - fattura fornitore

Il From mostra un indirizzo interno credibile. Il Reply-To reindirizza verso un account ProtonMail che l'attaccante controlla. Se il destinatario risponde senza verificare, la conversazione prosegue con l'attaccante.

Varianti avanzate. Gli attaccanti più sofisticati non usano un dominio gratuito evidente. Registrano un dominio di typosquatting vicino al dominio bersaglio: captaindns-support.com, captaindns.net, captaindnss.com. Questi domini sono più difficili da individuare in una lettura rapida del Reply-To. Un'altra variante consiste nell'usare un sottodominio ingannevole: captaindns.service-desk.com (il vero dominio è service-desk.com, non captaindns). Per il rilevamento automatizzato, mantieni una lista bianca di domini Reply-To autorizzati e segnala tutto ciò che non vi figura.

5. Catena Received anormalmente corta o lunga

Come lo sfrutta l'attaccante. Ogni server che elabora un'email aggiunge un'intestazione Received in cima alla pila. Un'email legittima attraversa generalmente da 3 a 5 hop (server del mittente, gateway in uscita, MX del destinatario, gateway in entrata, server di casella di posta). L'attaccante può manipolare questa catena in due modi. Prima opzione: inviare direttamente da uno script verso il MX del destinatario, producendo una catena con solo 1 o 2 hop, segnale di un invio non standard. Seconda opzione: iniettare intestazioni Received false per simulare un transito attraverso server legittimi, allungando artificialmente la catena.

Perché i filtri lo ignorano. I gateway non contano sistematicamente il numero di hop e non verificano la coerenza temporale tra i Received. Un'email con 8 hop di cui 3 falsificati supera i controlli standard se le intestazioni contraffatte sono ben formattate.

Cosa deve verificare il difensore. Contare le intestazioni Received e verificare due cose. Primo, la coerenza temporale: i timestamp devono progredire dal basso (primo hop) verso l'alto (ultimo hop). Un salto nel tempo (un hop datato prima del precedente) indica un'intestazione contraffatta. Secondo, il numero di hop: meno di 2 o più di 7 è anomalo per un'email professionale standard.

Esempio di intestazione (catena sospetta, troppo corta):

Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
    Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.attaccante.net) (45.77.200.18)
    by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100

Solo 2 hop. Nessun server in uscita, nessun gateway del mittente. Il messaggio è stato inviato direttamente da un nodo di invio verso il MX di captaindns.com, segnale di un invio tramite script, non di un server di posta aziendale.

La tecnica delle intestazioni Received contraffatte. Un attaccante più sofisticato inserisce intestazioni Received false per simulare un transito attraverso server legittimi. Aggiunge per esempio un hop Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com in fondo alla pila. La trappola: i server di ricezione aggiungono le intestazioni Received in cima alla pila, non in fondo. Le intestazioni in fondo sono le più vecchie e le prime ad essere state aggiunte. Un'intestazione Received che afferma di provenire da un server interno ma che si trova in fondo alla pila (prima del primo hop legittimo) è un'intestazione contraffatta dal mittente. Verifica sempre la coerenza della catena partendo dal fondo.

6. Assenza di TLS sul primo hop (STARTTLS mancante)

Come lo sfrutta l'attaccante. L'attaccante usa un server configurato senza supporto TLS o disabilita volontariamente STARTTLS. L'obiettivo non è la crittografia in se, ma ciò che rivela la sua assenza. Un server di posta legittimo nel 2026 supporta STARTTLS. Un server che invia in chiaro è probabilmente uno script, uno strumento di attacco o un server compromesso. L'assenza di TLS può anche indicare un attacco di downgrade SMTP, dove un attaccante intercetta la negoziazione TLS per forzare la trasmissione in chiaro.

Perché i filtri lo ignorano. I gateway non bloccano le email ricevute senza TLS. Il protocollo SMTP è progettato per funzionare in chiaro con TLS come estensione opzionale. Molti gateway accettano connessioni non cifrate per non perdere posta legittima proveniente da server datati. Il fatto che il primo hop sia in chiaro non è un criterio di filtraggio standard.

Cosa deve verificare il difensore. Nella prima intestazione Received (la più in basso nella pila), cercare la menzione with ESMTPS (connessione TLS) contro with SMTP o with ESMTP (connessione in chiaro). Un'email professionale nel 2026 dovrebbe sempre transitare con TLS attivato sul primo hop.

Esempio di intestazione:

Received: from send-node.attaccante.net (45.77.200.18)
    by mail-gw.captaindns.com with SMTP;
    Thu, 27 Mar 2026 09:15:20 +0100

La menzione with SMTP (senza la S di ESMTPS) indica una connessione in chiaro. Un server di posta aziendale legittimo avrebbe with ESMTPS o with TLS. Questa assenza di crittografia è un segnale debole ma significativo quando combinato con altri indicatori.

7. X-Mailer o User-Agent sospetto

Come lo sfrutta l'attaccante. I client di posta e i server inseriscono un'intestazione X-Mailer o User-Agent che identifica il software utilizzato. Gli attaccanti usano script Python (libreria smtplib o aiosmtplib), strumenti di invio di massa (GoPhish, King Phisher, Social Engineering Toolkit) o framework proprietari. Alcuni attaccanti omettono questa intestazione (il che è già un segnale), altri la falsificano per imitare un client legittimo (Outlook, Thunderbird). Le contraffazioni sono spesso imperfette: una versione inesistente, un formato di stringa incoerente o un X-Mailer che non corrisponde alle altre intestazioni presenti.

Perché i filtri lo ignorano. Il X-Mailer non è un'intestazione standardizzata dalle RFC. I gateway non lo considerano un criterio di sicurezza e non mantengono un database di firme di client malevoli. Un'email inviata da GoPhish con un X-Mailer falsificato Microsoft Outlook 16.0 supera i filtri se il contenuto e la reputazione IP sono puliti.

Cosa deve verificare il difensore. Cercare l'intestazione X-Mailer o User-Agent. Un User-Agent Python (Python/3.11 aiosmtplib/2.0) è un segnale forte. L'assenza totale di X-Mailer su un'email che dovrebbe provenire da Outlook è sospetta. Una versione di Outlook che non esiste (per esempio Microsoft Outlook 17.5 quando l'ultima versione è 16.x) tradisce una contraffazione.

Esempio di intestazione:

X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "Servizio IT" <it-support@captaindns.com>
Subject: Aggiornamento obbligatorio della tua password

Un'email di "aggiornamento password" inviata da uno script Python. Nessun servizio IT legittimo invia email critiche tramite uno script Python con aiosmtplib. Questa intestazione tradisce uno strumento di attacco o un test di phishing interno.

8. Message-ID con dominio incoerente

Come lo sfrutta l'attaccante. L'intestazione Message-ID è un identificatore unico generato dal server di invio. Contiene tipicamente un hash o un identificatore casuale seguito dal dominio del server che lo ha generato. L'attaccante che falsifica il From @captaindns.com ma invia dal proprio server genera un Message-ID con il proprio dominio o un identificatore generico. Questo disallineamento tra il dominio del From e il dominio nel Message-ID rivela l'infrastruttura reale dell'attaccante.

Perché i filtri lo ignorano. Il Message-ID viene usato per il tracciamento dei thread di conversazione e la deduplicazione, non per la sicurezza. I gateway non confrontano il dominio del Message-ID con il dominio del From. È un'intestazione tecnica che pochi sistemi di filtraggio analizzano dal punto di vista della coerenza.

Cosa deve verificare il difensore. Estrarre il dominio dopo il @ nel Message-ID e confrontarlo con il dominio del From. Un disallineamento indica che il messaggio è stato generato da un server che non appartiene al dominio mostrato.

Esempio di intestazione:

Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.attaccante.net>
From: "Risorse Umane" <rh@captaindns.com>

Il Message-ID rivela il server reale: vps-node-14.attaccante.net. Un'email legittima di captaindns.com avrebbe un Message-ID contenente captaindns.com o il dominio dell'ESP utilizzato (per esempio amazonses.com se l'organizzazione usa Amazon SES).

9. Intestazioni X-MS-Exchange o X-Google assenti

Come lo sfrutta l'attaccante. Le grandi piattaforme di posta inseriscono intestazioni proprietarie specifiche. Microsoft 365 aggiunge X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator e altre. Gmail aggiunge X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source. Quando un'email afferma di provenire da un dominio ospitato su Microsoft 365 ma non contiene nessuna di queste intestazioni, non ha transitato attraverso la piattaforma Microsoft. L'attaccante che falsifica il From @captaindns.com (dominio ospitato su M365) ma invia dal proprio server non può riprodurre queste intestazioni proprietarie in modo credibile.

Perché i filtri lo ignorano. I gateway di terze parti (non Microsoft, non Google) non conoscono la lista delle intestazioni proprietarie attese per ogni piattaforma. Anche i gateway integrati (Defender, Gmail) non verificano sistematicamente la coerenza tra il dominio From e la presenza delle intestazioni attese dalla piattaforma di hosting.

Cosa deve verificare il difensore. Identificare la piattaforma di hosting del dominio del From (M365, Google Workspace, altra). Verificare che le intestazioni proprietarie corrispondenti siano presenti. Un'email @captaindns.com (ospitata su M365) senza alcuna intestazione X-MS-Exchange-* non ha transitato attraverso Microsoft 365.

Esempio di intestazione (email sospetta, From M365 ma senza intestazioni Exchange):

From: "Direzione Finanziaria" <daf@captaindns.com>
To: contabilita@captaindns.com
Subject: Validazione urgente - bonifico internazionale
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.attaccante.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Nessuna intestazione X-MS-Exchange-*, nessun X-MS-Has-Attach, nessun X-OriginatorOrg. Se captaindns.com è ospitato su Microsoft 365, questa email non ha transitato attraverso la piattaforma. È una contraffazione inviata da un server esterno.

10. Content-Type multipart con allegato .html incapsulato

Come lo sfrutta l'attaccante. L'attaccante incapsula una pagina HTML di furto di credenziali (credential harvesting) nel corpo MIME del messaggio. A differenza di un allegato classico (.exe, .zip) che attiva gli allarmi, un file .html è spesso considerato inoffensivo dai gateway. Quando l'utente apre l'allegato HTML, il suo browser carica una pagina di login fittizia che imita Microsoft 365, Google Workspace o un altro servizio. Le credenziali inserite vengono inviate al server dell'attaccante. La pagina HTML può funzionare completamente offline (senza download di risorse esterne), rendendo il rilevamento da parte dei sandbox più difficile.

Perché i filtri lo ignorano. I file HTML non sono eseguibili e non contengono codice malevolo nel senso tradizionale (nessun shellcode, nessuna macro). I gateway che analizzano gli allegati si concentrano sui formati a rischio (.exe, .docm, .xlsm, .js, .vbs). Un file HTML è contenuto web statico, e molti filtri lo lasciano passare. Alcuni gateway analizzano le URL nell'HTML, ma se la pagina funziona offline con JavaScript incorporato, non ci sono URL da bloccare al momento della consegna.

Cosa deve verificare il difensore. Nelle intestazioni MIME, cercare una parte con Content-Type: text/html e Content-Disposition: attachment. La combinazione HTML + attachment è un segnale forte. Analizzare il contenuto del file HTML: la presenza di tag <form>, <input type="password"> o di JavaScript offuscato in un allegato HTML è quasi certamente malevola.

Esempio di intestazione:

Content-Type: multipart/mixed;
    boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Buongiorno, consulta il documento di sicurezza in allegato.

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...

Il boundary MIME contiene un allegato security-update-captaindns.html. Il corpo in base64 decodifica verso una pagina HTML con un modulo di login. Un'email legittima di CaptainDNS non invierebbe mai un file HTML in allegato per un "aggiornamento di sicurezza".

Tecniche di evasione nell'HTML incorporato. Gli attaccanti usano diverse tecniche per eludere i sandbox che analizzano gli allegati HTML. Il JavaScript può essere offuscato (codifica base64, concatenazione di stringhe, esecuzione dinamica di codice). La pagina può verificare se viene eseguita in un browser reale (rilevamento della risoluzione dello schermo, del movimento del mouse, dei plugin) e attivare il modulo di phishing solo se le condizioni sono soddisfatte. Alcune pagine HTML usano il protocollo data: o Blob URL per costruire dinamicamente il modulo, rendendo inefficace l'analisi statica. Nel 2025 e 2026, gli allegati .svg contenenti JavaScript incorporato sono diventati una variante sempre più comune di questa tecnica, poiché gli SVG sono ancora meno sorvegliati dei file HTML.

Combinare gli indicatori: la potenza dello scoring multi-segnale

Presi singolarmente, ogni indicatore può avere una spiegazione legittima. Un Return-Path diverso dal From è normale quando un ESP invia per conto di un'organizzazione. Un DKIM firmato da un dominio di terze parti è standard con SendGrid o Amazon SES. Una catena Received corta può provenire da un server on-premise che invia direttamente.

La potenza di questi 10 indicatori emerge quando li si combina. Un'email che presenta un solo indicatore merita una verifica. Un'email che presenta tre indicatori o più è quasi certamente malevola. Il principio è lo scoring multi-segnale: attribuire un punteggio a ogni indicatore rilevato e scalare quando il punteggio cumulato supera una soglia.

Esempio di scoring per un'email sospetta:

Indicatore rilevato	Punteggio
Return-Path ≠ From (dominio sconosciuto)	+2
DKIM firmato da dominio di terze parti non ESP	+2
SPF pass + DMARC fail	+3
Reply-To verso dominio gratuito	+3
Catena Received < 3 hop	+1
Assenza di TLS sul primo hop	+1
X-Mailer Python/script	+2
Message-ID dominio ≠ From	+2
Assenza intestazioni X-MS-Exchange (dominio M365)	+3
Allegato HTML	+2

Una soglia di 5 punti attiva una segnalazione per revisione SOC. Una soglia di 8 punti attiva una quarantena automatica. Questo scoring può essere implementato nelle regole di trasporto Exchange/Gmail o in un SIEM.

In pratica, le email di spear-phishing sofisticate combinano generalmente da 3 a 5 indicatori. Gli indicatori 1 (disallineamento Return-Path), 3 (SPF pass + DMARC fail) e 8 (Message-ID incoerente) compaiono insieme nella maggior parte dei casi di spoofing di dominio. Gli indicatori 4 (Reply-To divergente) e 9 (assenza di intestazioni proprietarie) caratterizzano gli attacchi BEC (Business Email Compromise). La combinazione 5 (catena Received corta) + 6 (assenza TLS) + 7 (X-Mailer script) tradisce un invio da uno strumento di attacco.

La lezione è chiara: non giudicare mai un'email da un solo indicatore. Costruisci uno scoring multi-segnale adattato al tuo ambiente e calibra le soglie analizzando le tue email legittime e i tuoi incidenti passati.

Come rilevare questi segnali dopo il gateway

Analisi manuale con uno strumento di ispezione

Per gli incidenti individuali (un utente segnala un'email sospetta), l'analisi manuale delle intestazioni resta il metodo più rapido. L'utente esporta le intestazioni grezze dal suo client email (in Outlook: File > Proprietà > Intestazioni Internet; in Gmail: i tre puntini > Mostra originale). L'analista SOC incolla le intestazioni in uno strumento di analisi che scompone ogni intestazione e evidenzia le anomalie.

I punti da verificare in priorità durante l'analisi manuale:

1. Return-Path vs From: domini identici o giustificazione legittima del disallineamento?
2. DKIM d= vs From: la firma copre il dominio corretto?
3. Authentication-Results: combinazione spf=pass + dmarc=fail?
4. Reply-To: dominio coerente con il From?
5. Catena Received: numero di hop, coerenza temporale, presenza di TLS?
6. Message-ID: dominio coerente con il From?
7. Intestazioni proprietarie: presenti se il dominio è ospitato su M365/Gmail?
8. Parti MIME: allegato HTML sospetto?

Regole di trasporto Exchange/Gmail per il marcaggio automatico

Per un rilevamento sistematico, le regole di trasporto (mail flow rules) in Exchange Online o le regole di routing in Google Workspace permettono di marcare automaticamente i messaggi che presentano determinati indicatori.

Esempio di regola Exchange Online per rilevare il disallineamento Reply-To:

Condizione: l'intestazione Reply-To contiene un dominio diverso dal dominio del From, E il dominio del Reply-To non è in una lista bianca (domini interni, ESP autorizzati). Azione: aggiungere un banner di avviso al messaggio ("Questo messaggio ha un Reply-To diverso dal mittente mostrato") e marcarlo per revisione SOC.

Esempio di regola per rilevare l'assenza di intestazioni M365:

Condizione: il dominio del From è un dominio interno ospitato su M365, E l'intestazione X-MS-Exchange-Organization-AuthSource è assente. Azione: mettere in quarantena per revisione manuale.

Queste regole non sostituiscono il gateway ma aggiungono uno strato di rilevamento post-filtraggio mirato ai segnali che il gateway ignora.

Integrazione SIEM per il rilevamento su larga scala

Per le organizzazioni con un volume significativo di email, l'integrazione con un SIEM (Microsoft Sentinel, Splunk, Elastic Security) permette di automatizzare il rilevamento e la correlazione. I log di trasporto Exchange o Gmail contengono i risultati di autenticazione, le intestazioni chiave e i metadati di routing. Regole di rilevamento personalizzate cercano i seguenti schemi:

• Volume anomalo di email con dmarc=fail action=none per un dominio interno
• Email in entrata con Reply-To verso domini gratuiti quando il From è un dominio interno
• Messaggi senza intestazioni X-MS-Exchange-* quando il dominio From è ospitato su M365
• Allegati HTML in email in entrata con un From interno

La correlazione SIEM permette anche di incrociare un'email sospetta con le connessioni di rete: se un utente apre un allegato HTML alle 09:15 e una connessione sospetta a M365 da un IP straniero compare alle 09:18, l'incidente viene rilevato in quasi tempo reale.

Il legame con la deliverability e lo spam

I 10 indicatori descritti in questo articolo non riguardano solo la sicurezza. Influenzano anche la deliverability delle tue stesse email. Se il tuo dominio presenta gli stessi segnali di un'email di phishing (Return-Path incoerente, DKIM non allineato, DMARC su p=none), i gateway dei destinatari tratteranno i tuoi messaggi con sospetto. Le tue email legittime finiscono nello spam perché la tua configurazione DNS e le tue intestazioni attivano gli stessi segnali che gli attaccanti sfruttano.

Correggere le tue intestazioni (allineare SPF e DKIM, passare DMARC a p=reject, configurare Message-ID coerenti) ha un doppio beneficio: rafforzare la sicurezza del tuo dominio contro lo spoofing E migliorare la deliverability delle tue email legittime. È la stessa griglia di lettura applicata a due obiettivi complementari.

Piano d'azione

1. Verificare le tue ultime 50 email sospette: recupera le intestazioni delle email segnalate dai tuoi utenti nell'ultimo mese e analizzale con i 10 indicatori. Questo audit rivela i tipi di attacchi che superano il tuo gateway.
2. Creare regole di trasporto per gli indicatori 1, 4 e 5: il disallineamento Return-Path/From, il Reply-To divergente e la catena Received anomala sono i tre segnali più facili da rilevare automaticamente tramite regole Exchange o Gmail.
3. Rafforzare DMARC verso p=quarantine o p=reject: finché la tua policy DMARC è p=none, gli indicatori 1, 2 e 3 restano sfruttabili senza conseguenze per l'attaccante. Ricordiamo che solo il 4% dei domini applica p=reject (Valimail, 2025): ogni dominio che migra riduce la superficie di attacco per tutto l'ecosistema. Usa il nostro strumento di verifica DMARC (link nel banner qui sopra) per verificare la tua policy attuale.
4. Formare i team SOC sui segnali di allarme delle intestazioni: i dipendenti formati segnalano quattro volte più minacce di quelli non formati, il 21% contro il 5% (Verizon DBIR, 2025). I 10 indicatori di questo articolo dovrebbero fare parte della procedura standard di analisi degli incidenti email. Crea una checklist stampabile che gli analisti consultino durante ogni indagine.
5. Integrare l'analisi delle intestazioni nel processo di incident response: le organizzazioni che integrano l'IA nella loro pipeline di sicurezza riducono il ciclo di violazione di 80 giorni e risparmiano in media 1,9 milioni di dollari per incidente (IBM, Cost of a Data Breach 2025). Ogni email sospetta segnalata deve passare attraverso un'analisi post-gateway sistematica prima di essere classificata come falso positivo.
6. Ri-testare mensilmente con email di test: inviati email che riproducano ciascuno dei 10 indicatori. Se il tuo gateway le lascia passare e le tue regole di trasporto non le segnalano, le tue difese hanno un punto cieco.

FAQ

Perché il mio gateway email non rileva questi segnali?

I gateway sono ottimizzati per il filtraggio di massa: reputazione IP, contenuto sospetto, firme malware. I 10 indicatori descritti qui riguardano la coerenza delle intestazioni, un ambito che i gateway non analizzano in profondità. Il disallineamento Return-Path/From o l'assenza di intestazioni proprietarie non sono criteri di filtraggio standard nella maggior parte dei SEG sul mercato.

Quali filtri email sono i più vulnerabili a questi aggiramento?

I gateway che si concentrano esclusivamente sulla reputazione IP e sull'analisi del contenuto sono i più vulnerabili. Le soluzioni che integrano analisi comportamentale e verifica dell'allineamento DMARC sono meglio posizionate, ma nessun gateway sul mercato verifica i 10 indicatori in modo esaustivo. Ecco perché l'analisi post-gateway resta necessaria.

Come creare una regola di trasporto Exchange per rilevare il disallineamento Reply-To?

Nell'Exchange Admin Center, crea una regola di flusso di posta con la condizione "Un'intestazione del messaggio include" sull'intestazione Reply-To. Combinala con la condizione "Il dominio del mittente è" per targetizzare i domini interni. L'azione raccomandata è aggiungere un avviso visibile al destinatario e marcare il messaggio per revisione SOC. Testa in modalità audit per due settimane prima di attivare il blocco.

L'analisi delle intestazioni può essere automatizzata?

Sì. I risultati di autenticazione e le intestazioni chiave sono accessibili nei log di trasporto Exchange Online e Gmail. Un SIEM (Sentinel, Splunk, Elastic) può ingerire questi log e applicare regole di rilevamento sui 10 indicatori. Per le organizzazioni senza SIEM, le regole di trasporto Exchange/Gmail offrono un primo livello di automazione accessibile.

Queste tecniche di aggiramento funzionano contro Gmail e Outlook nativi?

Gmail e Outlook dispongono dei propri livelli di filtraggio (Gmail usa modelli ML avanzati, Outlook integra Defender). Questi filtri sono migliori della media sull'allineamento DMARC e il rilevamento di Reply-To sospetti. Ma non sono infallibili: gli indicatori 5 (catena Received anomala), 7 (X-Mailer sospetto), 8 (Message-ID incoerente) e 10 (allegato HTML) restano punti ciechi anche per queste piattaforme.

Come formare il mio team SOC all'analisi delle intestazioni?

Inizia con un workshop pratico di 2 ore con email reali (anonimizzate) che presentano ciascuno dei 10 indicatori. Crea una checklist stampabile che gli analisti consultino durante ogni indagine. Integra l'analisi delle intestazioni negli esercizi di tabletop simulation e nelle simulazioni di phishing interne. L'obiettivo è che ogni analista SOC possa identificare i 10 indicatori in meno di 5 minuti per email.

Bisogna sostituire il mio gateway email per proteggersi?

No. I 10 indicatori sono complementi al gateway, non sostituti. Il gateway resta indispensabile per bloccare lo spam di massa, i malware conosciuti e le campagne di phishing generiche. L'obiettivo è aggiungere uno strato di rilevamento post-gateway (regole di trasporto, analisi SOC, SIEM) mirato agli attacchi sofisticati che il filtraggio standard non cattura.

Come testare se il mio gateway ignora questi segnali?

Inviati email di test che riproducano ciascuno dei 10 indicatori da un server esterno. Per il disallineamento Return-Path: configura un MAIL FROM diverso dal From. Per il DKIM di terze parti: firma con un dominio diverso. Per il Reply-To: inserisci un Reply-To verso un dominio esterno. Documenta quali email superano il gateway e quali vengono bloccate. Questo test rivela i punti ciechi specifici della tua configurazione.

Glossario

• Return-Path: intestazione inserita dal server di ricezione contenente l'indirizzo della busta SMTP (MAIL FROM). Usata per le notifiche di mancata consegna (bounce). Verificata da SPF.
• DKIM-Signature: intestazione contenente la firma crittografica di un messaggio. Il campo d= identifica il dominio firmatario, s= il selettore della chiave pubblica.
• Allineamento DMARC: verifica che il dominio del From corrisponda al dominio verificato da SPF (allineamento SPF) o al dominio firmatario DKIM (allineamento DKIM). L'allineamento può essere rigoroso (corrispondenza esatta) o rilassato (corrispondenza sul dominio organizzativo).
• Reply-To: intestazione opzionale che indica l'indirizzo verso cui devono essere dirette le risposte. Può differire dal From.
• Catena Received: serie di intestazioni aggiunte da ogni server (hop) che ha elaborato il messaggio. Lette dall'alto in basso, tracciano il percorso del messaggio dall'ultimo hop (alto) al primo (basso).
• STARTTLS: estensione SMTP che permette di avviare una connessione cifrata TLS su una connessione SMTP esistente. Visibile nelle intestazioni Received dalla menzione with ESMTPS.
• X-Mailer: intestazione opzionale che identifica il software client usato per inviare il messaggio. Non standardizzata dalle RFC, ma ampiamente usata dai client di posta.
• Message-ID: identificatore unico assegnato a ogni messaggio dal server di invio. Formato: <identificatore@dominio>. Usato per il concatenamento delle conversazioni è la deduplicazione.
• MIME (Multipurpose Internet Mail Extensions): standard di codifica delle email che permette allegati, contenuto HTML e caratteri non ASCII. Definito dall'intestazione Content-Type.
• Content-Disposition: intestazione MIME che indica se una parte del messaggio deve essere mostrata inline (inline) o proposta per il download (attachment).
• Mittente di busta (envelope sender): indirizzo SMTP usato durante il comando MAIL FROM nella sessione SMTP. Distinto dall'indirizzo nell'intestazione From visibile dal destinatario.

---

Le tue intestazioni nascondono segnali sospetti? Incolla le tue intestazioni grezze nel nostro analizzatore di intestazioni email per una diagnosi automatica che copre l'autenticazione, il routing e le anomalie descritte in questo articolo.

---

Fonti

• RFC 5322 - Internet Message Format
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Microsoft - Enhanced Filtering for Connectors in Exchange Online
• MITRE ATT&CK T1566 - Phishing