Identity Threat Defense

Oltre il gateway: come i criminali informatici progettano intenzionalmente attacchi per eludere la sicurezza dell’email

Share with your network!

I criminali informatici di oggi comprendono il funzionamento dei gateway email. Sanno che i gateway analizzano le intestazioni dei messaggi, ispezionano il corpo dei messaggi ed esaminano con attenzione gli allegati. Inoltre, quando qualcosa appare sospetto, il gateway email pone allegati e URL in una sandbox per osservarne il comportamento.  

I criminali informatici sono consapevoli di quanto sopra e hanno modificato la loro metodologia d’attacco. Sebbene in passato privilegiassero gli allegati dannosi, ora ricorrono sempre più spesso a URL dannosi. Secondo il nostro ultimo report Il fattore umano vol. 2: phishing e minacce basate su URL, gli URL vengono utilizzati 4 volte di più degli allegati nelle email dannose.  

Per eludere il rilevamento, i criminali informatici spesso nascondono i componenti dannosi di un URL dietro barriere di autenticazione o una logica condizionale per aggirare le misure di sicurezza. Una sandbox non è in grado di emulare con facilità il comportamento reale degli utenti. Per questo motivo, senza quell'autentica interazione dell'utente, la sandbox potrebbe non raggiungere mai la parte dannosa dell'attacco. I criminali informatici non si limitano a manipolare gli URL. Trovano modi per aggirare completamente l'infrastruttura di sicurezza dell’email sfruttando le relazioni di fiducia nelle piattaforme di collaborazione. 

Di seguito sono riportati tre casi d'uso reali che abbiamo osservato, in cui i criminali informatici hanno intenzionalmente progettato i propri attacchi per eludere le protezioni esistenti. Ciascun caso illustra una strategia di elusione diversa. 

Caso d'uso 1: exploit di verifica del collegamento, nascosto dietro l'autenticazione 

In questo primo caso d'uso, un criminale informatico include nella propria email un link che sembra legittimo. Potrebbe trattarsi, ad esempio, di un documento condiviso su OneDrive, un file Dropbox o una richiesta DocuSign.  

Funzionamento 

Quando la sandbox del gateway email analizza l'URL, rileva solo una pagina di autenticazione che richiede agli utenti di verificare la loro identità. Agli utenti viene chiesto di inserire un indirizzo email, fornire una password o completare un codice CAPTCHA o effettuare un’altra verifica per dimostrare che sono umani.  

L'elusione critica: questo URL iniziale non contiene alcun codice dannoso.  

Dal punto di vista del sistema di sicurezza, questa pagina sembra una pagina di verifica standard per un servizio di condivisione di file legittimo. La sandbox determina che l'URL è sicuro e il messaggio viene recapitato nella casella email del destinatario. 

Solo dopo che l'utente ha fatto clic sul link e inserito i propri dati di autenticazione, il server web autorizza l'accesso alla pagina dannosa. Tale pagina potrebbe essere un modulo di raccolta delle credenziali d’accesso, un download di malware o un sito di phishing sofisticato. L'attacco si nasconde dietro il requisito di autenticazione. È invisibile all’analisi automatica che ha già classificato l'email come sicura. 

Figure 1. Example of a link verification exploit. Figura 1. Esempio di exploit di verifica del link. 

L'implicazione 

Anche se il gateway email può rilevare l'URL dannoso noto dietro la pagina di autenticazione, non sarà mai in grado di analizzare la pagina. L'URL iniziale è effettivamente pulito. Il gateway email non riscriverà l'URL per analisi future e recapiterà il messaggio. La minaccia si rivela solo al termine dell'analisi di sicurezza e quando l'utente è stato convinto ad autenticarsi. Questa tecnica trasforma efficacemente le funzionalità di sicurezza legittime (pagine di autenticazione) in un meccanismo di elusione. 

Caso d'uso 2: il miraggio della sandbox—rilevare il rilevatore 

In questo attacco più sofisticato, l'infrastruttura web del criminale informatico è progettata specificamente per rilevare se un visitatore è umano o un sistema di sicurezza automatizzato. 

Funzionamento 

Quando un'email contenente un URL dannoso raggiunge il gateway email, il sistema di sicurezza la apre in un ambiente sandbox in modo da analizzare il suo comportamento prima della consegna. 

Tuttavia, il server web del criminale informatico analizza le richieste HTTP in entrata per distinguere tra sandbox e utenti reali. I server web possono esaminare i seguenti elementi: 

  • Stringhe dell’agente utente. Le sandbox utilizzano spesso agenti utente identificabili che rivelano che si tratta di strumenti di sicurezza automatizzati. 
  • Indirizzi IP. Questo indica loro se una richiesta proviene da intervalli IP di fornitori di sicurezza noti o da una rete di data center. 
  • Intestazioni HTTP. I modelli nelle intestazioni come Referer e Accept-Language e altri attributi di richiesta differiscono tra gli strumenti automatizzati e i browser autentici. 
  • Esecuzione di JavaScript. Indica loro se il client esegue completamente JavaScript, poiché alcune sandbox potrebbero caricare le pagine senza eseguire completamente lo script. 
  • Modelli di accesso. Cercano di capire se si tratta di un accesso diretto all’URL o di un percorso naturale a partire da una ricerca o da un client email. Figure 2. Workflow of a webpage request. 

Figura 2. Flusso di lavoro di una richiesta di pagina web. 

Sulla base di questa analisi, se la richiesta sembra provenire da una sandbox, il server del criminale informatico reindirizza verso una pagina web sicura o la diffonde.  

Di conseguenza, quando il sistema di sicurezza analizza l'URL, stabilisce che il contenuto è sicuro e l’email viene recapitata. Per contro, quando un utente fa clic sullo stesso link dal suo dispositivo aziendale con un browser standard, il server del criminale informatico reindirizza verso il contenuto dannoso o lo diffonde. 

L'implicazione 

Quando i criminali informatici utilizzano una logica lato server per distinguere analizzatori di sicurezza e obiettivi umani, l’analisi statica o una singola verifica dell’URL non è sufficiente. Il semplice fatto di eseguire un’ispezione automatizzata può essere rilevato e sfruttato, innescando un continuo gioco del gatto e del topo che oggi i team di sicurezza faticano a vincere. 

Caso d'uso 3: la backdoor di Google Calendar—sfruttamento degli ecosistemi di fiducia 

Questo vettore d’attacco è particolarmente insidioso perché non prevede l'invio di un’email. Quindi, può eludere completamente i gateway email. 

Funzionamento 

Il processo si svolge come segue: 

  1. Ricognizione iniziale. Il criminale informatico identifica che l’azienda XYZ utilizza Google Workspace. 
  2. Creazione dell'account. Il criminale informatico crea un account Gmail gratuito: badguy@gmail.com. 
  3. Identificazione degli obiettivi. Ottiene un elenco di indirizzi email dei collaboratori dell’azienda XYZ. 
  4. Creazione di un evento del calendario. Nel proprio account @gmail.com, il criminale informatico crea un invito di calendario che include:  
  • Indirizzi email dei collaboratori premi di mira 
  • Un URL di phishing incorporato nei dettagli dell'evento 
  • Un allegato PDF dannoso (camuffato da documenti delle riunioni) 

5.  Il passo fondamentale. Invece di fare clic su "Invia l’invito", il criminale informatico salva semplicemente l'evento del calendario come bozza. 

Nel giro di pochi secondi, l'invito del calendario appare nei calendari di tutti i collaboratori della società XYZ presi di mira. Include l'URL di phishing e l'allegato dannoso. Poiché non è stata inviata alcuna email, il gateway di sicurezza dell’email non rileva mai la minaccia. Non ha mai l'opportunità di analizzare l'URL o l'allegato. 

Figure 3. Example of a Google calendar exploit. Figura 3. Esempio di exploit di Google Calendar. 

Questo attacco sfrutta il rapporto di fiducia intrinseco a Google Workspace. Quando gli inviti del calendario vengono creati all'interno dell'ecosistema Google, si sincronizzano direttamente tra gli account senza attivare i tradizionali meccanismi di consegna delle email.  

I controlli di sicurezza progettati per ispezionare il traffico email vengono completamente elusi perché la minaccia opera a livello applicativo, non a livello di trasporto delle email.  

Dal punto di vista dell'utente, tutto ciò che vede è un invito a calendario legittimo, per esempio per una "revisione trimestrale delle attività" o una "riunione con un fornitore", con una formattazione professionale e documenti allegati. Poiché è arrivato tramite un'applicazione affidabile, non vi è motivo di sospettare che abbia eluso un qualche controllo di sicurezza. 

L'implicazione 

Questo caso d'uso rivela una lacuna critica: le aziende che si affidano esclusivamente alla protezione del gateway email non vedono le minacce veicolate dagli strumenti di collaborazione.  

Poiché il lavoro è sempre più collaborativo e basato sul cloud, i criminali informatici adattano le loro tecniche per sfruttare le relazioni di fiducia tra le applicazioni integrate. 

Il percorso da seguire 

Per difendersi da queste tattiche di evasione, devi cambiare radicalmente l'approccio alla sicurezza. Piuttosto che affidarsi a un unico punto di ispezione, hai bisogno di una protezione completa e in profondità. Ecco cosa cercare: 

1. Protezione avanzata dell’email con analisi continua 

Hai bisogno di un sistema di sicurezza che vada oltre l'ispezione iniziale della pagina e assicuri un monitoraggio continuo e un'analisi dopo la consegna. Ciò include: 

  • Una rivalutazione continua degli URL anche dopo la consegna delle email 
  • Un’analisi comportamentale che rileva le anomalie nei modelli di interazione degli utenti 
  • Una protezione al momento del clic che analizza gli URL nel momento in cui gli utenti vi accedono, non solo quando arrivano le email. 

2. Protezione della collaborazione integrata nel browser 

Le minacce arrivano sempre più spesso attraverso piattaforme di collaborazione piuttosto che tramite email. Ecco perché sono necessari controlli di sicurezza che operino dove gli utenti interagiscono con i contenuti: nel browser. La protezione nativa del browser può: 

  • Analizzare i reindirizzamenti e gli URL multi-nidificati in tempo reale, indipendentemente dal modo in cui sono stati trasmessi 
  • Controllare le minacce su ogni pagina del percorso dell'utente, non solo sulla landing page iniziale 
  • Rilevare i comportamenti dannosi negli inviti del calendario, nei documenti condivisi e nelle piattaforme di messaggistica 

3. Difesa incentrata sulle persone 

Nessuna tecnologia può sostituire la sensibilizzazione alla sicurezza. Devi formare i tuoi utenti affinché comprendano: 

  • Perché dovrebbero essere diffidenti nei confronti degli URL che richiedono un'autenticazione immediata—soprattutto quando le credenziali d’accesso sono fornite nel messaggio. 
  • Come riconoscere e segnalare gli inviti di calendario insoliti provenienti da soggetti esterni 
  • I controlli di sicurezza non sono infallibili e il loro giudizio rimane un livello di difesa fondamentale. 

Conclusione 

I casi d'uso sopra descritti non sono teorici, ma rappresentano modelli di attacco attivi osservati in ambienti aziendali reali. Se parti dal principio che il tuo gateway email offre una protezione completa, operi con un punto cieco pericoloso. 

Scopri come Proofpoint Prime Threat Protection offre una protezione completa e multilivello contro queste tattiche di evasione intenzionali.