Il Postino Lavora di Notte

Sono le 02:17. Il SIEM ha alzato un flag su 192.168.1.45 - una workstation del reparto contabilità. Non è un alert critico, ma è strano: connessione TCP in uscita sulla porta 25 verso un IP esterno. Le workstations non parlano sulla porta 25. Non dovrebbero farlo mai.

Apro il pcap.

Come viaggia un'email

#

Prima di capire perché quell'alert è anomalo, devo capire come funziona il traffico email in una rete normale. L'email viaggia in due fasi separate con protocolli diversi.

sequenceDiagram
    participant MUA as Client (MUA)
    participant MSA as Mail Server aziendale
    participant DNS as DNS MX record
    participant MTA2 as MTA Destinatario
    participant MDA as Mailbox (MDA)
    participant Client2 as Client IMAP

    MUA->>MSA: SMTP porta 587 con STARTTLS autenticato
    Note over MUA,MSA: client verso mail server aziendale
    MSA->>DNS: query MX destinatario.com
    DNS-->>MSA: smtp.destinatario.com priority 10
    MSA->>MTA2: SMTP porta 25 server-to-server
    Note over MSA,MTA2: mail server verso mail server remoto
    MTA2->>MDA: deposita nella mailbox
    Client2->>MDA: IMAP porta 993 con TLS
    MDA-->>Client2: email consegnata

La distinzione critica: la porta 25 è per il traffico server-to-server. Un MTA aziendale la usa per consegnare email a un MTA remoto. Una workstation non ha motivo di aprire connessioni dirette sulla porta 25 - il suo compito è parlare con il mail server aziendale sulla porta 587, autenticata e cifrata.

Quattro protocolli, due fasi

#

Fase 1 - consegna: SMTP porta 587 dal client al mail server aziendale (autenticato, con STARTTLS), poi SMTP porta 25 tra mail server. SMTP non sa nulla di mailbox o storage - consegna e sparisce.

Fase 2 - lettura: IMAP (porta 993) o POP3 (porta 995). La differenza tra i due conta in un'indagine forense.

In un'indagine, IMAP è più amico del Blue Team: le email sono ancora lì, accessibili.

STARTTLS aggiorna una connessione non cifrata a TLS dopo il primo handshake. SMTPS invece è cifrata dall'inizio. La porta 587 è la porta di submission client-to-server - autenticata. La porta 25 è riservata al traffico MTA-to-MTA: gli ISP la bloccano agli utenti normali proprio per prevenire spam. Una workstation che apre connessioni sulla porta 25 bypassa completamente questo meccanismo.

Come il MTA trova il destinatario

#

Ogni volta che un mail server deve consegnare un'email a utente@example.com, esegue una query DNS per il record MX di example.com. I record MX hanno una priorità: numero più basso corrisponde al server preferito. Se il primario è irraggiungibile, il MTA prova il successivo in ordine.

dig MX gmail.com
# gmail-smtp-in.l.google.com      5    primo tentativo
# alt1.gmail-smtp-in.l.google.com 10
# alt2.gmail-smtp-in.l.google.com 20
# alt3.gmail-smtp-in.l.google.com 30

È un failover nativo del protocollo, senza configurazioni aggiuntive. Dopo aver risolto il record MX, il MTA esegue una seconda query DNS per l'IP del server e apre la connessione SMTP sulla porta 25.

Cosa vedo nel pcap

#

tshark -r capture.pcap -Y "smtp" \
  -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter

192.168.1.45  203.0.113.42  EHLO   [192.168.1.45]
192.168.1.45  203.0.113.42  MAIL   FROM:<cfo@azienda.com>
192.168.1.45  203.0.113.42  RCPT   TO:<raccolta77@hotmail.com>
192.168.1.45  203.0.113.42  DATA
# output simulato

La workstation 192.168.1.45 ha aperto una connessione SMTP diretta sulla porta 25 verso un IP esterno. Ha inviato un'email da cfo@azienda.com verso un indirizzo Hotmail esterno. Il mittente è il CFO - ma chi ha effettivamente spedito questa email?

Il campo MAIL FROM: in SMTP è liberamente falsificabile. Chiunque può costruire un'email con qualsiasi mittente senza avere accesso a quell'account. Lo spoofing non richiede credenziali.

Il contenuto del DATA

#

Seguo lo stream TCP per leggere il body.

tshark -r capture.pcap -q -z "follow,tcp,ascii,0"

Content-Type: multipart/mixed;
  boundary="--boundary-0x7f4a2b"

----boundary-0x7f4a2b
Content-Type: text/plain

Allego il file come da accordi.

----boundary-0x7f4a2b
Content-Type: application/octet-stream; name="report_q1.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report_q1.zip"

UEsDBBQAAAAIABt2...
# output simulato

Un allegato in base64. La dimensione nel MAIL FROM era SIZE=2847291 - quasi 3MB.

base64 non è cifratura. È una codifica che permette di trasmettere dati binari su un canale testuale. Qualsiasi analista con accesso al pcap estrae il file in pochi secondi con base64 -d. Su SMTP senza TLS, mittente, destinatario, subject, body e allegati viaggiano come una cartolina aperta. Un SIZE grande su connessioni SMTP in chiaro è un segnale di possibile exfiltration.

Il flusso dell'investigazione

#

graph TD
    A["Alert SIEM\n192.168.1.45 porta 25 verso IP esterno"] --> B["tshark filtra SMTP\nidentifica comandi e IP"]
    B --> C["MAIL FROM: cfo@azienda.com\nRCPT TO: indirizzo esterno\nSIZE: 2.8MB"]
    C --> D1["Anomalia 1\nWorkstation non usa porta 25\nquel traffico e' del MTA"]
    C --> D2["Anomalia 2\nMAIL FROM falsificato\nSMTP non verifica il mittente"]
    C --> D3["Anomalia 3\nAllegato 3MB in base64\nSMTP senza TLS = chiaro"]
    D1 --> E["Isola la workstation\nAnalisi malware"]
    D2 --> E
    D3 --> E

IoC e tecniche

#

Mitigazione

#

# Identifica quale processo sta aprendo connessioni sulla porta 25
ss -tulnp | grep :25

# Verifica record SPF del dominio
dig TXT azienda.com | grep spf

# Verifica DKIM (sostituisci il selector corretto)
dig TXT default._domainkey.azienda.com

# Verifica DMARC
dig TXT _dmarc.azienda.com

Checklist:

• Bloccare la porta 25 in uscita su tutte le workstations - solo il mail server aziendale deve usarla
• Configurare SPF con -all (hard fail) per il dominio
• Implementare DKIM con chiave a 2048 bit minimo
• DMARC con p=quarantine come minimo, p=reject come obiettivo
• Alert su qualsiasi connessione SMTP diretta (porta 25) da host non classificati come mail server
• TLS obbligatorio su porta 587 - nessun fallback in chiaro

Un'ultima cosa da fissare. IMAPS (porta 993) cifra il canale tra client e server. Le email sul server restano accessibili al provider - in chiaro per chi gestisce l'infrastruttura. Solo la cifratura end-to-end (S/MIME, PGP, ProtonMail) impedisce al provider di leggere il contenuto. In un'indagine interna con autorizzazione, le email sul server mail aziendale sono recuperabili: IMAP le lascia lì.

exit 0

#

Una workstation che parla direttamente sulla porta 25 è come un impiegato che porta lui stesso le lettere all'ufficio postale internazionale invece di affidarle al corriere aziendale. Tecnicamente funziona. Praticamente, è il segnale che qualcosa ha preso il controllo del processo di consegna.

SMTP ha quasi cinquant'anni. È stato progettato per un internet di fiducia che non esiste più. SPF, DKIM e DMARC sono stati aggiunti decenni dopo come rattoppi. Sono rattoppi necessari: un dominio senza questi tre record DNS non si chiede se verrà usato per phishing. Si chiede quando.

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