↓ Skip to main content
u-random
u-random
  1. Blog/

Il CEO Non Ha Scritto Quella Email

·4 mins
facile attacco
Network-Defense Dfir
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Il CEO Non Ha Scritto Quella Email

TL;DR
  • BEC (Business Email Compromise) non richiede malware - basta falsificare il campo From: in SMTP
  • SPF, DKIM e DMARC sono i tre record DNS che rendono verificabile l'identità del mittente
  • Un dominio senza questi tre record è impersonabile in cinque minuti da chiunque
  • Leggere gli header Received: di un'email dal basso verso l'alto rivela il percorso reale del messaggio
▶ $ history
  • dig TXT dominio.com
  • dig TXT _dmarc.dominio.com

Arianna gestisce i pagamenti. Quella mattina ha ricevuto un'email dal CEO: cambio fornitore urgente, nuovo IBAN, bonifico entro fine giornata. 47.000 euro. Il tono era quello di sempre - formale, diretto, niente spiegazioni superflue.

Ha quasi premuto invio.

Per fortuna ha chiamato prima. Il CEO non sapeva nulla.

L'email non era sua
#

La prima cosa che faccio è aprire l'email originale e leggere gli header completi - non il campo From: che vede l'utente, ma il tracciato reale del messaggio.

Gli header Received: si leggono dal basso verso l'alto - il più in basso è il primo hop, il più in alto è l'ultimo prima della inbox.

Received: from mail-out.sendgridfake.net (185.220.x.x)
  by mx1.azienda.com with ESMTP
  for <arianna@azienda.com>; Mon, 19 May 2026 09:14:22 +0200

Received: from [192.168.1.5] (unknown)
  by sendgridfake.net with SMTP
  for <arianna@azienda.com>; Mon, 19 May 2026 09:14:18 +0200

From: Marco Bianchi <m.bianchi@azienda.com>
Reply-To: pagamenti-conf@gmail.com

Tre segnali in un colpo solo:

  1. Il server mittente è sendgridfake.net - non ha niente a che fare con azienda.com
  2. Il campo Reply-To punta a un account Gmail - non al CEO
  3. Il From: mostra azienda.com ma il messaggio non è partito da lì

Come funziona il BEC
#

SMTP non verifica l'identità del mittente. Chiunque può scrivere qualsiasi indirizzo nel campo From: senza avere accesso a quella casella. È come scrivere su una busta postale il nome di qualcun altro come mittente.

sequenceDiagram
    participant A as Attaccante (185.220.x.x)
    participant MTA as Mail Server azienda.com
    participant AR as Arianna

    A->>MTA: EHLO sendgridfake.net
    A->>MTA: MAIL FROM: m.bianchi@azienda.com
    Note over A,MTA: SMTP non chiede credenziali per MAIL FROM
    A->>MTA: RCPT TO: arianna@azienda.com
    A->>MTA: DATA - corpo email + Reply-To: gmail
    MTA->>AR: Consegnata con From: CEO
    AR->>AR: Legge "CEO" nel campo From
    AR-->>A: Risponde all'attaccante (Reply-To)

Senza protezioni DNS, il server di azienda.com accetta l'email e la consegna. Non ha strumenti per verificare che quell'IP sia autorizzato a spedire per conto del dominio.

Verifica la postura del dominio
#

Controllo i record DNS di azienda.com.

# SPF - chi è autorizzato a spedire email per questo dominio?
dig TXT azienda.com | grep spf
# (nessun output)

# DKIM - firma crittografica
dig TXT default._domainkey.azienda.com
# (nessun output)

# DMARC - policy su cosa fare se SPF/DKIM falliscono
dig TXT _dmarc.azienda.com
# (nessun output)

Nessun record. Il dominio è completamente aperto - chiunque può spedire email "da" azienda.com senza che il server ricevente possa rilevarlo. L'attaccante lo sapeva.

Come SPF/DKIM/DMARC avrebbero bloccato questo
#

graph TD
    EMAIL["Email da 185.220.x.x
    From: m.bianchi@azienda.com"]

    EMAIL --> SPF["Controllo SPF
    185.220.x.x è nella lista SPF di azienda.com?"]
    EMAIL --> DKIM["Controllo DKIM
    La firma corrisponde alla chiave pubblica DNS?"]

    SPF -->|"NO - IP non autorizzato"| FAIL1["SPF FAIL"]
    DKIM -->|"NO - nessuna firma presente"| FAIL2["DKIM FAIL"]

    FAIL1 --> DMARC["DMARC: entrambi falliti
    p=reject → email rifiutata"]
    FAIL2 --> DMARC

    DMARC -->|"con DMARC attivo"| BLOCK["Email non consegnata
    Report inviato all'admin"]
    DMARC -->|"senza DMARC"| INBOX["Email in inbox
    Arianna quasi paga 47k"]

IoC e tecniche
#

TipoValoreContestoMITRE ATT&CK
IP185.220.x.xServer SMTP attaccanteT1566.001
Dominiosendgridfake.netMail server non autorizzatoT1566.001
TecnicaMAIL FROM falsificato su dominio senza SPFBEC via email spoofingT1586.002
TecnicaReply-To Gmail - risposta va all'attaccanteIntercettazione comunicazioniT1534

Correggere la postura
#

# Verifica l'IP del tuo mail server legittimo
dig MX azienda.com
dig A mail.azienda.com

# Record SPF - autorizza solo il tuo mail server
# Aggiungere in DNS come TXT su @:
# v=spf1 include:_spf.provider.it -all

# Verifica DMARC dopo configurazione
dig TXT _dmarc.azienda.com
# Deve rispondere: v=DMARC1; p=reject; rua=mailto:dmarc@azienda.com

Checklist minima per qualsiasi dominio che invia email:

  • Record SPF con -all (hard fail) - non ~all (soft fail)
  • DKIM configurato sul mail server con chiave a 2048 bit
  • DMARC con p=quarantine inizialmente, poi p=reject dopo verifica
  • Monitorare i report DMARC - segnalano ogni tentativo di spoofing
  • Procedura interna per pagamenti: verifica telefonica obbligatoria per IBAN nuovi

exit 0
#

L'attaccante non ha violato nessun sistema. Non ha rubato credenziali, non ha installato malware, non ha fatto niente di tecnicamente sofisticato. Ha solo scritto un'email sapendo che dall'altra parte c'era un processo aziendale prevedibile e un dominio senza difese.

47.000 euro non sono partiti perché Arianna ha chiamato. Non perché il sistema l'abbia fermata.

SPF, DKIM e DMARC costano zero euro e si configurano in un pomeriggio. L'assenza di quei tre record DNS è una scelta - spesso inconsapevole, sempre rischiosa.

Comandi usati: dig Concetti correlati: smtp, dns-resolution-flow

Related