I tuoi filtri di sicurezza sono stati appena umiliati. Se pensi che un’e-mail con SPF e DKIM validi sia sinonimo di sicurezza, sei ufficialmente in pericolo. L’attacco di cui stiamo per parlare non bussa alla porta: ha le chiavi di casa e indossa la divisa del padrone. Per difendersi da minacce così sofisticate, la tecnologia da sola non basta più; serve che ogni dipendente sappia cosa guardare. Investire in un corso di cyber security awareness per utenti aziendali è l’unico modo per creare un firewall umano capace di bloccare ciò che i software lasciano passare.
Negli ultimi giorni mi è capitato di analizzare un’e-mail che, a prima vista, risultava perfettamente legittima dal punto di vista dei controlli di sicurezza: SPF, DKIM e DMARC tutti in stato pass, dominio del mittente ad alta reputazione e nessun elemento tecnico tipicamente associato a campagne di phishing tradizionali.
Entrando negli header, però, emerge un dettaglio fondamentale: il messaggio non è stato consegnato tramite una normale sessione SMTP, ma è stato iniettato direttamente nell’infrastruttura Google tramite Gmail API. La presenza della dicitura gmailapi.google.com with HTTPSREST indica chiaramente che il flusso di invio è avvenuto via API, cioè attraverso una chiamata applicativa verso i sistemi di Google, e non tramite un mail server esterno.
Il cambio di paradigma: il modello di attacco
Questo cambia completamente il modello di attacco. In uno scenario di questo tipo il messaggio nasce già all’interno del perimetro di fiducia del provider. Non esiste un relay esterno, non esiste un IP sorgente da valutare e non c’è una catena SMTP classica da analizzare. Il flusso reale è semplicemente applicazione, Gmail API, infrastruttura Google e consegna finale nella mailbox del destinatario.
Proprio per questo motivo l’autenticazione risulta perfetta. La firma DKIM viene applicata direttamente da Google e la valutazione SPF non è più legata a un indirizzo IP di terze parti. Di conseguenza anche DMARC risulta conforme. Dal punto di vista dei controlli standard, il messaggio è indistinguibile da una comunicazione legittima generata dai sistemi del provider.
L’illusione dell’identità: il dominio google.com
Un altro elemento che salta all’occhio è il mittente, configurato con un indirizzo sul dominio google.com. Questo non implica automaticamente che sia stato compromesso un account interno di Google. Quando si utilizzano le API è sufficiente che l’identità di invio sia stata autorizzata come “send-as” o che l’account disponga delle corrette configurazioni di invio. In altre parole, il punto critico non è il dominio in sé, ma il modo in cui viene gestita l’identità di spedizione all’interno dell’ecosistema del provider.
Negli header compare anche la stringa “named unknown” associata a un identificativo numerico. Non si tratta di un hostname o di un sistema remoto, ma di un identificativo interno legato al progetto o al client che ha effettuato la chiamata alle API. È un ulteriore indicatore che il messaggio è stato generato tramite un canale applicativo e non tramite un’infrastruttura di posta tradizionale.
L’assenza di artefatti SMTP
Coerentemente con questo modello, mancano completamente gli artefatti tipici di una consegna SMTP:
- Non ci sono IP pubblici da blacklistare.
- Non ci sono host di relay intermedi.
- Non è presente una vera catena di server di posta.
Il messaggio viene creato direttamente all’interno della piattaforma. Dal punto di vista dell’attaccante, il prerequisito non è la compromissione della mailbox del destinatario e nemmeno, necessariamente, quella di un account reale del mittente. È sufficiente disporre di un account Google valido o, più in generale, di un token OAuth o di un progetto API con gli scope necessari per l’invio tramite Gmail API, insieme a un’identità di invio configurata correttamente. Il vettore non è più lo spoofing del protocollo SMTP, ma l’abuso di un canale di invio legittimo messo a disposizione dal provider.
L’inefficacia dei controlli tradizionali
È anche il motivo per cui molti controlli di sicurezza email risultano inefficaci in questo scenario. La maggior parte dei sistemi di protezione si basa ancora su concetti come reputazione degli IP, analisi dei relay SMTP o individuazione di infrastrutture di invio sospette. Qui, invece, l’infrastruttura è quella ufficiale del provider, il dominio che firma il messaggio è legittimo e l’origine del traffico si colloca interamente all’interno del perimetro di fiducia.
Il contenuto del messaggio analizzato conferma un’ulteriore evoluzione delle tecniche di social engineering. Non erano presenti link, allegati o payload. Il testo era costruito per sembrare una richiesta operativa credibile e urgente, con l’unico obiettivo di ottenere una risposta e avviare una conversazione. L’attacco vero e proprio viene rimandato alle interazioni successive, quando il thread è ormai percepito come legittimo. È una tecnica di “conversation seeding” sempre più utilizzata nelle campagne di phishing mirate e nelle operazioni di BEC evoluto.
Evoluzione del Business Email Compromise (BEC)
La differenza rispetto al Business Email Compromise classico è rilevante. Nel BEC tradizionale l’attaccante opera dall’interno di una mailbox realmente compromessa. In questo caso, invece, non c’è evidenza di una compromissione diretta di una casella di posta del dominio mittente. Il messaggio viene generato da un canale applicativo legittimo e l’elemento sfruttato è la fiducia implicita nelle integrazioni e nelle identità di invio.
Dall’analisi degli header emerge quindi in modo piuttosto chiaro che ci troviamo di fronte a un’email generata tramite Gmail API, firmata correttamente dai sistemi Google e priva di qualunque indicatore di trasporto sospetto. Non è un caso di spoofing. È un caso di abuso di canali di invio ufficiali del provider, resi disponibili tramite API e configurazioni di invio. Una dinamica che rappresenta una naturale evoluzione delle campagne di phishing e di social engineering ad alta affidabilità.
Come Nexsys può aiutarti a mitigare il rischio
Per questo tipo di scenari Nexsys affianca le organizzazioni con servizi di assessment avanzato sulla sicurezza della posta e delle integrazioni cloud, focalizzati su Microsoft 365, Entra ID e sulle superfici di attacco applicative, incluse API, identity delegation e configurazioni di invio. L’obiettivo è individuare configurazioni “send-as”, applicazioni OAuth e flussi di automazione che possono essere abusati come canali di invio trusted.
Attraverso i servizi di hardening e governance di Nexsys su Microsoft 365 ed Entra ID vengono definite policy di controllo sulle applicazioni enterprise, revisione degli scope Graph e Gmail-like API, monitoraggio delle identity non interattive e integrazione con i sistemi di threat detection e response. Questo consente di ridurre in modo concreto il rischio di abuso dei canali applicativi, oggi uno dei vettori più sottovalutati nelle architetture cloud.
Per le aziende che vogliono verificare in modo strutturato la propria esposizione a questo tipo di attacco, Nexsys fornisce servizi di security assessment mirati sulla posta elettronica e sui flussi di integrazione, con report tecnico dettagliato, evidenze di configurazione e piano di remediation operativo.
Non aspettare che un’email “trusted” buchi le tue difese. Oltre all’analisi tecnica, il fattore umano resta l’anello determinante: proteggi il tuo team con un
