Team MailSniper
Autore
.arpa e IPv6 reverse DNS per far passare phishing inosservatoSe stai leggendo questo, probabilmente hai visto email di phishing passare che non avrebbero dovuto passare. SPF: pass. DKIM: pass. DMARC: pass. Reputazione dominio: ok. Eppure il tuo collega ha quasi cliccato su un link che scaricava un payload.
Non sei tu a sbagliare qualcosa. È una tecnica che sta girando tra i gruppi di threat actor più svegli in circolazione.
Il trucco: usare la zona DNS .arpa.
Quando il tuo gateway email riceve un messaggio, fa un controllo di reputazione sull'IP mittente. Manda una query PTR — cioè una ricerca DNS inversa — per sapere a che nome corrisponde quell'indirizzo IP.
In IPv4 queste query finiscono nella zona in-addr.arpa. In IPv6 finiscono nella zona ip6.arpa. Entrambe sono parte della stessa radice .arpa, che è un dominio speciale gestito da IANA, usato per infrastruttura DNS di base.
Ecco il punto critico: molti sistemi di reputazione trattano .arpa come dominio infrastrutturale legittimo. Non è in nessuna blacklist. Non ha storia di spam. È tecnicamente "neutro".
I threat actor hanno capito che se costruiscono i loro PTR record in modo da puntare a sottodomini .arpa con nomi apparentemente legittimi, il controllo di reputazione vede qualcosa come:
PTR: mail.gateway.telco-provider.ip6.arpa...e alcuni gateway lo trattano come un provider di telecomunicazioni affidabile. Spoiler: non lo è.
IPv6 complica ulteriormente la situazione. Un indirizzo IPv6 completo ha 128 bit, che in formato PTR diventano una stringa di 32 caratteri separati da punti, al contrario. Così:
2001:db8::1Diventa:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpaMolti strumenti di reputation check fanno parsing di queste stringhe in modo superficiale. Cercano pattern noti, nomi di provider, keyword sospette. Una stringa così lunga e strutturata li manda in confusione.
E i threat actor li aiutano: registrano blocchi IPv6 (facili da ottenere, spesso gratuiti o quasi) e impostano PTR record che sembrano appartenere a provider legittimi.
Per seguire questa guida ti serve:
Non devi essere un esperto di IPv6, ma aiuta capire la struttura base degli indirizzi e dei PTR record.
Il primo passo è capire se il problema esiste già nel tuo ambiente. Vai nei log SMTP del tuo gateway e cerca connessioni dove il PTR dell'IP mittente contiene .arpa ma non segue pattern di provider noti.
Se hai accesso a una console Linux con i log, prova:
grep -i 'ip6.arpa\|in-addr.arpa' /var/log/maillog | grep -v 'PASS\|authenticated'Cosa cerchi: PTR record che hanno struttura strana, come sottodomini .arpa con nomi che sembrano provider ma che non riesci a verificare.
Esempio di PTR legittimo:
mail.example-provider.comEsempio di PTR sospetto:
outbound.smtp.eu-west-mail.ip6.arpaIl secondo sembra legittimo. Non lo è.
Per ogni PTR che ti insospettisce, fai una verifica forward-confirmed reverse DNS (FCrDNS). Cioè:
# Esempio con dig
dig -x 2001:db8::1 +short
# Risposta: outbound.smtp.eu-west-mail.ip6.arpa.
dig AAAA outbound.smtp.eu-west-mail.ip6.arpa +short
# Risposta: deve tornare 2001:db8::1 per essere validaSe la risposta forward non corrisponde all'IP originale, o non risponde affatto, hai un PTR non verificabile. Questo è un segnale di allarme.
Molti gateway, purtroppo, non fanno questa verifica FCrDNS per default.
Qui dipende dal tuo gateway, ma il concetto è universale: rifiuta o metti in quarantena le email che arrivano da IP il cui PTR record non supera il check FCrDNS.
Su Postfix, per esempio:
# In main.cf
smtpd_recipient_restrictions =
reject_unknown_reverse_client_hostname,
...reject_unknown_reverse_client_hostname rifiuta connessioni da IP che non hanno PTR record valido. Per casi più sofisticati come questo, aggiungi anche la verifica forward:
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
...Su altri gateway (Postfix, Exim, Exchange) la logica è simile ma la sintassi cambia. Cerca la voce corrispondente a "reverse DNS validation" o "FCrDNS check" nelle impostazioni.
Un PTR legittimo di un provider email finisce con un hostname comprensibile, non con la notazione numerica raw. Aggiungi una regola per bloccare o aumentare lo spam score quando il PTR record è nella forma pura ip6.arpa senza prefisso descrittivo.
Esempio di regola SpamAssassin:
header ARPA_PTR_ONLY X-Originating-IP =~ /^\d/
rawbody __ARPA_RDNS /\.ip6\.arpa\.?$/
meta ARPA_SUSPICIOUS ARPA_PTR_ONLY && __ARPA_RDNS
score ARPA_SUSPICIOUS 3.5Adatta la logica al tuo sistema. L'idea è semplice: un IP mittente che ha come PTR solo la notazione reverse numerica, senza un hostname human-readable, è altamente sospetto per l'invio di email.
Qui si apre un problema inverso: se il tuo server invia email via IPv6 senza PTR record configurato correttamente, potresti essere tu a finire nei filtri degli altri.
Verifica:
# Trova il tuo IPv6 di uscita
curl -6 https://ifconfig.me
# Poi fai il PTR check
dig -x [tuo-ipv6] +shortSe non risponde nulla, o risponde con la notazione raw, contatta il tuo provider e fai configurare il PTR record correttamente. Esempio di come dovrebbe essere:
mail.tuaazienda.it.Non come appare in molte configurazioni di default:
2001-db8-0-0-0-0-0-1.provider-ipv6-range.ip6.arpa.Gli header Received: di un'email mostrano tutti i server che l'hanno attraversata. Estrai gli IP da questi header e cross-checkali contro le principali blacklist IPv6.
Comando rapido:
# Estrai IP da un file .eml
grep -i 'received: from' email.eml | grep -oE '([0-9a-fA-F:]+:+[0-9a-fA-F:]+)'
# Per ogni IP, controlla su DNSBL IPv6
dig +short 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.black.uribl.comLe principali DNSBL con supporto IPv6 includono URIBL, Spamhaus ZEN, e Barracuda Reputation Block List. Molti gateway le interrogano solo per IPv4 — verifica che il tuo lo faccia anche per IPv6.
Dopo aver applicato le modifiche, ecco come testare che tutto funzioni.
Test 1 — Invio da IP con PTR sospetto
Usa un servizio come mail-tester.com o costruisci un test interno con un server che abbia un PTR non verificabile. Il tuo gateway dovrebbe rifiutare o mettere in quarantena.
Test 2 — Verifica nei log
# Su Postfix
grep 'unknown reverse client' /var/log/mail.log | tail -20
# Dovresti vedere righe tipo:
# reject: RCPT from unknown[2001:db8::1]: 450 Client host rejected: cannot find your hostnameTest 3 — Cross-check reputazione IPv6
MXToolbox ha un tool di lookup blacklist: inserisci un indirizzo IPv6 sospetto e verifica quante liste lo segnalano. Se un mittente è pulito su tutte le liste ma arriva con PTR .arpa senza FCrDNS valido, la tua nuova regola dovrebbe comunque bloccarlo.
Tool utili:
dig -x [ip] +short — PTR lookup direttohost [ip] — alternativa più leggibileLa regola FCrDNS blocca email legittime da grandi provider
Alcuni provider (soprattutto cinesi o di certi mercati emergenti) non hanno PTR configurati correttamente anche per indirizzi legittimi. Aggiungi whitelist per ASN o range IP di provider certificati prima di abilitare il blocco duro. Inizia con un'azione di log-only per 48 ore per vedere cosa verrebbe bloccato.
Il gateway non supporta query PTR per IPv6
È più comune di quanto pensi, soprattutto su gateway datati. Verifica la versione del software e le note di rilascio. Se IPv6 PTR non è supportato, considera di abilitare la preferenza IPv4 per le connessioni SMTP in entrata nel breve termine mentre aggiorni.
Il PTR sembra legittimo ma l'email è phishing
Queste tecniche evolvono: PTR valido + dominio registrato da pochi giorni + nessuna storia email. Affianca la verifica PTR con controlli sull'età del dominio (puoi usare whois o servizi RDAP) e con analisi comportamentale del contenuto. Un gateway che analizza solo il perimetro SMTP non è sufficiente — serve analisi del contenuto. I filtri di MailSniper usano AI semantica che legge il contenuto del messaggio, non solo l'infrastruttura di invio.
Score spam alto ma messaggio non in quarantena
Verifica le soglie configurate. Molti gateway hanno soglie di default troppo alte (score 10+) per non generare falsi positivi. Con tecniche evasive come questa, un'email può accumulate 4-5 punti senza superare la soglia. Considera di abbassarla a 6-7 con test graduali.
Log mostrano PTR diverso da quello che vedi con dig
Il gateway potrebbe usare resolver DNS diversi con TTL cacheati. Svuota la cache del resolver DNS locale del gateway dopo ogni modifica alle regole PTR.
Questa tecnica è l'ennesima conferma che le difese perimetrali basate su reputazione non bastano da sole. I threat actor hanno imparato a navigare nell'infrastruttura DNS come se fosse casa loro.
I passi da portare a casa:
Per chi non vuole gestire tutto questo manualmente, ha senso guardare a soluzioni che fanno questi controlli in automatico e in tempo reale — come funziona MailSniper mostra nel dettaglio come vengono gestiti i controlli reputazione IP, PTR e analisi contenuto in parallelo.
Il DNS è vecchio quanto internet. Ma usarlo contro di te? Questo è nuovo.
Team MailSniper
Team MailSniper
Esperti di sicurezza email e protezione aziendale. Il team MailSniper analizza quotidianamente le minacce informatiche per offrire soluzioni all'avanguardia alle aziende italiane.
Scopri chi siamoUna nuova campagna di attacco sfrutta OAuth per rubare token di accesso a Microsoft 365, bypassando completamente l'autenticazione a più fattori. Ecco l'analisi tecnica completa con indicatori MITRE ATT&CK e mitigazioni prioritarie.
LeggiTA446 (SEABORGIUM/ColdRiver) sta sfruttando DarkSword per prendere di mira iPhone aziendali via phishing email. Ecco cosa fare lato server di posta e MDM per non ritrovarti a fare incident response il venerdì sera.
LeggiPer anni 'ho un iPhone' è sembrata una risposta sufficiente a qualsiasi preoccupazione sulla sicurezza. Poi è arrivato DarkSword — e quella certezza ha cominciato a scricchiolare.
LeggiRicevi i nostri articoli e consigli direttamente nella tua casella di posta.
Scopri come MailSniper puo' proteggere le tue email aziendali con tecnologia AI di livello enterprise.