Abuso legittimo dell'infrastruttura: la tecnica di phishing che aggira l'autenticazione delle e-mail

Immaginate questa situazione: un’e-mail di phishing arriva direttamente nella casella di posta aziendale. Il gateway di sicurezza la analizza e le assegna una valutazione eccellente. Sender Policy Framework (SPF): superata. DomainKeys Identified Mail (DKIM): superata. Domain-based Message Authentication, Reporting, and Conformance (DMARC): superata. L’e-mail è altamente dannosa, eppure ha superato senza difficoltà ogni singolo livello di difesa. Perché? Perché è stata inviata tramite un’infrastruttura cloud affidabile, di cui i vostri strumenti di sicurezza e-mail si fidano già ciecamente.

Questa strategia è nota come “abuso delle infrastrutture” o, nel contesto del phishing via e-mail, come “living off the land”. Anziché creare domini sospetti e di breve durata, gli autori degli attacchi instradano le loro campagne attraverso piattaforme cloud consolidate e di grande affidabilità per l’invio di e-mail.

Si tratta di una tendenza di grande portata. Il Rapporto sulle minacce 2026 di Cloudflare evidenzia come le piattaforme di posta elettronica basate su cloud siano vettori ampiamente sfruttati per sofisticate operazioni di phishing e distribuzione di malware, e sottolinea che gli attori statali stanno integrando attivamente questa tecnica nelle loro strategie operative. Anche i ricercatori di sicurezza di Kaspersky hanno rilevato un aumento sostenuto e significativo degli attacchi di phishing inviati tramite le principali infrastrutture cloud a partire da gennaio 2026.

Che cos’è l’abuso legittimo delle infrastrutture?

L'abuso di infrastrutture legittime consiste nell'inviare campagne di phishing tramite piattaforme cloud consolidate e affidabili per l'invio di e-mail, anziché ricorrere a infrastrutture create appositamente dagli autori degli attacchi. Nel mondo della sicurezza degli endpoint, l'espressione “living off the land” indica che gli hacker utilizzano strumenti di sistema nativi e affidabili, come PowerShell, per sferrare attacchi, anziché installare malware evidenti. Ciò rende il rilevamento incredibilmente difficile, poiché lo strumento stesso fa parte del sistema. L'abuso di infrastrutture legittime applica esattamente la stessa logica alla consegna delle e-mail.

Anziché acquistare un dominio oggetto di typosquatting o configurare un server di posta dedicato a fini malevoli, i truffatori compromettono o affittano spazio su piattaforme cloud consolidate per la gestione della posta transazionale. Piattaforme come Amazon SES, SendGrid e Mailjet sono spesso prese di mira, non perché la loro sicurezza interna sia carente, ma perché la loro reputazione impeccabile come mittenti rappresenta la risorsa più preziosa per un aggressore.

Gli autori delle minacce ottengono solitamente l'accesso attraverso due metodi principali:

• Furto di credenziali e chiavi API: gli autori degli attacchi rubano o acquistano chiavi API legittime e credenziali di account di posta elettronica esistenti nel cloud. Secondo Abnormal AI, queste vengono regolarmente scambiate sui forum dedicati alla criminalità informatica a prezzi che partono da soli 15 dollari.
• Domini di invio compromessi: gli autori degli attacchi compromettono un dominio aziendale esistente che dispone già di un fornitore di servizi di posta elettronica (ESP) basato su cloud configurato come mittente autorizzato, beneficiando direttamente della reputazione di mittente maturata nel corso degli anni.

Perché l’autenticazione delle e-mail non basta a impedirlo

Il divario nell'autenticazione

Protocolli come SPF, DKIM e DMARC sono stati sviluppati per rispondere a una domanda fondamentale: questa e-mail proviene da un mittente autorizzato per questo dominio? Quando un malintenzionato dirotta un account cloud legittimo o sfrutta la configurazione dell’ESP autorizzato di un dominio, la risposta tecnica è un sì categorico.

L'e-mail supera il controllo SPF perché l'IP del provider cloud è esplicitamente indicato nel record SPF del dominio. Supera il controllo DKIM perché la piattaforma firma il messaggio con la chiave crittografica corretta del dominio. Infine, il controllo DMARC viene superato perché entrambi i protocolli sono perfettamente allineati.

Non si tratta di un bug né di un difetto di DMARC. I protocolli funzionano esattamente come previsto. Il problema è che verificare se un mittente è autorizzato è una cosa completamente diversa dal verificare se l’account sia ancora sotto il controllo dell’effettivo proprietario del dominio.

Perché il blocco basato sulla reputazione IP non funziona

Gli strumenti di sicurezza tradizionali si basano in larga misura sui punteggi di reputazione degli indirizzi IP. Se un indirizzo IP invia spam, viene bloccato. Tuttavia, quando si tratta di contrastare gli abusi dell'infrastruttura, questo approccio fallisce completamente.

Gli indirizzi IP di provenienza appartengono a grandi fornitori di servizi cloud che gestiscono ogni giorno miliardi di e-mail aziendali legittime. Se un Secure Email Gateway (SEG) bloccasse tali intervalli di IP per fermare una campagna di phishing, provocherebbe tassi di falsi positivi catastrofici e bloccherebbe importanti e-mail aziendali di migliaia di società non coinvolte. L’autore dell’attacco si nasconde all’interno di una massa enorme e affidabile.

Perché i gateway di posta elettronica sicuri non riescono a individuarlo

La maggior parte dei sistemi SEG valuta la posta in arrivo in base all'anzianità del dominio, alla presenza di link noti come dannosi e alle firme degli allegati. In questi attacchi, il dominio mittente è pulito, la reputazione è impeccabile e il punteggio di autenticazione è pari al 100%.

Inoltre, gli autori degli attacchi neutralizzano gli scanner di link sfruttando tecniche di phishing basate sul reindirizzamento aperto integrate negli stessi ESP. Utilizzano gli URL di tracciamento dei clic nativi della piattaforma, che sono universalmente inseriti nelle liste bianche dai gateway di posta elettronica. Il gateway esegue la scansione del link di tracciamento, considerato altamente affidabile, e lascia passare il messaggio; la destinazione dannosa viene attivata solo tramite un reindirizzamento nel momento esatto in cui l’utente clicca sul link.

In altre varianti, i truffatori aggirano completamente la scansione degli URL inviando esche di tipo Business Email Compromise (BEC) prive di link. Allegano file PDF "puliti" contenenti dettagli di pagamento fissi oppure inseriscono thread di posta elettronica contraffatti relativi a modifiche delle fatture, facendo leva su tecniche di ingegneria sociale nascoste all’interno di un’e-mail autenticata.

Come si manifesta nella pratica l'abuso legittimo delle infrastrutture

In pratica, queste campagne si basano su esche che trasmettono un senso di estrema urgenza e ispirano grande fiducia. Tra le tecniche più comuni figurano false notifiche relative alle firme elettroniche che si spacciano per piattaforme come DocuSign, avvisi urgenti sulla sicurezza degli account e frodi relative alle fatture rivolte agli uffici contabili.

La causa di questi attacchi è da ricercarsi direttamente in una scarsa gestione delle credenziali. Gli hacker raccolgono regolarmente chiavi API da configurazioni AWS Identity and Access Management (IAM) esposte in repository GitHub pubblici o da file .env inseriti accidentalmente nel codice.

Quando tutti i fattori convergono, i risultati sono sorprendenti. Un caso reale documentato da IRONSCALES nell’aprile 2026 ha messo in luce un’e-mail di phishing che ha ottenuto un punteggio perfetto di 100 su 100 nell’autenticazione composita di Microsoft. L’e-mail si spacciava per uno strumento di gestione dei progetti ampiamente utilizzato e ha superato senza problemi i controlli SPF, DKIM e DMARC, poiché era stata inviata tramite la configurazione cloud legittima di un provider di servizi di posta elettronica (ESP) associata a un dominio compromesso.

Messaggio in entrata: Risultati dell'autenticazione

Risultato principale: Autenticato, ma non legittimo. (Sulla base di un incidente documentato da IRONSCALES, aprile 2026).

Cosa funziona davvero: una difesa realistica

Per dirla senza mezzi termini: non esiste uno strumento in grado di bloccare completamente questa categoria di attacchi. Chiunque affermi che il solo DMARC possa bloccare automaticamente gli abusi dell’infrastruttura sta facendo promesse irrealistiche. Tuttavia, un approccio realistico e a più livelli riduce significativamente il rischio.

1. Monitoraggio DMARC: il tuo sistema di allerta precoce

Sebbene un’e-mail di phishing autenticata superi la convalida, i report aggregati DMARC (RUA) offrono una visibilità completa sul vostro ecosistema di posta in uscita. Se un malintenzionato ruba le vostre chiavi API e inizia a instradare lo spam attraverso una piattaforma cloud utilizzando il vostro dominio, quel massiccio picco di volume apparirà immediatamente nei vostri report.

L'analisi regolare dei report DMARC (RUA) consente di individuare tempestivamente gli utilizzi non autorizzati dell'infrastruttura, prima che si verifichino danni diffusi alla reputazione. Per i team che desiderano un rilevamento automatizzato, il DMARC Analyzer di PowerDMARC offre un monitoraggio continuo e avvisi in tempo reale sulle anomalie, per segnalare le fonti di invio inattese non appena compaiono.

2. Applicazione del DMARC: proteggi il traffico in uscita dal tuo dominio

Impostare la politica DMARC su p=reject garantisce che, qualora un malintenzionato tentasse di falsificare il tuo dominio attraverso canali non autorizzati al di fuori della tua infrastruttura cloud approvata, i messaggi vengano bloccati immediatamente. Inoltre, un’applicazione rigorosa rende il tuo dominio un bersaglio molto più difficile da colpire. I truffatori alla ricerca di facili vettori di abuso dell’infrastruttura preferiscono bersagli più vulnerabili che utilizzano una politica p=none poco rigorosa.

3. Sicurezza delle credenziali ESP: chiudere il punto di accesso

La strategia più diretta per prevenire il phishing delle credenziali consiste nel proteggere le chiavi dell'infrastruttura di invio.

• Applicare l'autenticazione a più fattori (MFA) a tutti gli account amministratore dell'ESP.
• Utilizzare chiavi API con un ambito di applicazione ben definito, limitate alle autorizzazioni minime necessarie.
• Aggiornare regolarmente le chiavi API di produzione.
• Implementare la scansione automatica del codice per garantire che le informazioni riservate non vengano mai inserite nei repository pubblici.
• Controlla settimanalmente i dashboard relativi all'utilizzo del tuo ESP per individuare eventuali picchi di volume insoliti o configurazioni di mittenti sconosciuti.

4. Sicurezza comportamentale della posta elettronica

Poiché i gateway tradizionali non riescono a contrastare le minacce provenienti da infrastrutture affidabili, è necessario un livello integrato di sicurezza e-mail nel cloud (ICES). Gli strumenti di sicurezza comportamentale basati sull’intelligenza artificiale analizzano il contesto anziché limitarsi a valutare la reputazione. Esaminano la cronologia delle comunicazioni, i volumi di invio tipici e i modelli linguistici. Se un account completamente autenticato invia improvvisamente una richiesta di fattura anomala a un destinatario insolito, gli strumenti comportamentali possono segnalarla e metterla in quarantena.

5. Formazione mirata sulla sensibilizzazione degli utenti

Se un’e-mail di phishing supera tutti i controlli tecnici di validazione, la difesa ricade sulle persone. I dipendenti devono essere formati per riconoscere che un’e-mail con un’immagine aziendale impeccabile, un indirizzo mittente corretto e nessun segnale di allarme tecnico può comunque rivelarsi una trappola se l’account sottostante è stato compromesso.

Insegnate al vostro team a verificare autonomamente qualsiasi istruzione di pagamento improvvisa o modifica del conto tramite un canale di comunicazione secondario e fuori banda (come una breve telefonata). Dovrebbero inoltre controllare attentamente le pagine di destinazione finali del browser prima di inserire le credenziali, indipendentemente da quanto sicuro potesse sembrare il link contenuto nell’e-mail iniziale.

Infine, ma non meno importante, i dipendenti possono semplicemente utilizzare uno strumento di verifica delle e-mail di phishing per ottenere un’analisi immediata delle minacce. Tutto ciò che devono fare è incollare il testo completo dell’e-mail, comprese le intestazioni, per verificare i dati di autenticazione, i segnali relativi al mittente, i link sospetti, i modelli di urgenza e altro ancora.

Parole finali

Il modello di minaccia aziendale ha subito un cambiamento radicale. Il phishing avanzato di oggi non si basa più su e-mail mal formattate inviate da domini casuali e sospetti. Attraverso l’abuso di infrastrutture legittime, gli aggressori sfruttano attivamente i servizi cloud che utilizziamo e di cui ci fidiamo ogni giorno, approfittando del divario tra l’autorizzazione del mittente e il controllo effettivo dell’identità.

La vostra strategia di difesa deve adattarsi a questa realtà. Sebbene i protocolli di autenticazione da soli non bastino a risolvere il problema, tenere sotto stretto controllo il vostro ambiente cambia completamente le carte in tavola.

Proteggi oggi stesso il tuo ecosistema di posta elettronica: vuoi sapere esattamente chi invia email a nome del tuo marchio? Assumi il controllo del tuo perimetro e ricevi avvisi in tempo reale sui comportamenti di invio inattesi con il DMARC Analyzer di PowerDMARC.

Domande frequenti

Se un'e-mail supera i controlli SPF, DKIM e DMARC, perché il mio gateway di sicurezza la lascia comunque passare?

Questo perché i gateway di sicurezza sono programmati per considerare affidabili proprio quei protocolli. Quando un’e-mail soddisfa perfettamente tutti e tre i criteri, il gateway ritiene di avere a che fare con una comunicazione legittima e autorizzata proveniente dal proprietario del dominio. I gateway verificano se l’infrastruttura è autorizzata a inviare l’e-mail, non chi si trova dietro la tastiera a scriverla.

Questo significa che DMARC non funziona o è inutile?

Niente affatto. DMARC sta facendo esattamente ciò per cui è stato progettato: impedire a malintenzionati a caso di falsificare il tuo nome di dominio dal nulla. Non è in grado di distinguere se un aggressore abbia acquistato una chiave API rubata o abbia dirottato il tuo account cloud effettivo. Pensa a DMARC come a una serratura di sicurezza high-tech: funziona perfettamente, a meno che il ladro non rubi le chiavi vere e proprie di casa tua.

Perché non possiamo semplicemente bloccare gli indirizzi IP da cui provengono queste e-mail di phishing?

Questo perché quegli indirizzi IP appartengono a servizi su larga scala e legittimi come Amazon SES o SendGrid. Ogni giorno, milioni di e-mail aziendali normali e sicure (come ricevute, conferme di volo e reimpostazioni di password) transitano proprio attraverso quegli stessi indirizzi IP. Se si blocca l'intervallo di indirizzi IP, si blocca il traffico legittimo insieme a quello indesiderato.

In che modo gli hacker riescono a ottenere le credenziali di queste piattaforme di posta elettronica nel cloud?

Di solito, si tratta di semplici errori umani. A volte gli sviluppatori lasciano accidentalmente esposte le chiavi API nei repository pubblici di GitHub oppure eseguono il commit di file come .env contenenti dati di accesso in chiaro. Altre volte, gli autori delle minacce acquistano semplicemente credenziali valide trapelate sui forum dedicati alla criminalità informatica per pochi spiccioli, spesso a un prezzo irrisorio come 15 dollari.

La formazione volta a sensibilizzare gli utenti può davvero essere d’aiuto nel caso in cui i filtri tecnici non funzionino?

Sì, ma bisogna cambiare il modo in cui si forma il personale. La formazione tradizionale insegna agli utenti a cercare “segnali di allarme” come indirizzi e-mail dall’aspetto sospetto o parametri di autenticazione non validi. Nel caso degli abusi dell’infrastruttura, questi segnali di allarme non sono presenti. La formazione deve concentrarsi su punti di controllo comportamentali, come ad esempio alzare il telefono per verificare qualsiasi richiesta improvvisa e fuori dal normale di denaro o di aggiornamenti sensibili relativi all’account, indipendentemente da quanto l’e-mail possa sembrare in regola.

• Informazioni su
• Ultimi messaggi

Milena Baghdasaryan

Specialista dei contenuti presso PowerDMARC

Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.

Ultimi messaggi di Milena Baghdasaryan (vedi tutti)

• Sicurezza della posta elettronica in America Latina: lo stato del DMARC e dell’autenticazione delle e-mail in America Latina nel 2026 - 30 giugno 2026
• Abuso legittimo delle infrastrutture: la tecnica di phishing che aggira l’autenticazione delle e-mail - 30 giugno 2026
• Come vendere servizi di sicurezza e-mail: una guida per gli MSP - 24 giugno 2026