Negli ultimi mesi è stata individuata una campagna di phishing altamente sofisticata, caratterizzata da spoofing dell’identità del mittente, l’inclusione di QR code dannosi e il bypass diretto dei email security gateway. Questa campagna di phishing è progettata con l’obiettivo primario di colpire dipendenti aziendali, in particolare quelli con accesso a sistemi interni, dati sensibili o piattaforme cloud-based (es. Portali HR, ambienti Microsoft 365).
L’uso dello spoofing per simulare un’email proveniente da sé stessi o da un collega interno aumenta drasticamente le probabilità che il destinatario interagisca con il contenuto, soprattutto in contesti dove l’automatismo e la fiducia nell’ambiente aziendale giocano un ruolo cruciale.
La scelta di testi generici ma plausibili (es. “Aggiornamento urgente sui benefit aziendali”) e la presentazione del contenuto in lingua inglese, mira a superare le barriere linguistiche nei contesti aziendali internazionali o presso organizzazioni che usano l’inglese come lingua franca interna.
Questa combinazione di ingegneria sociale, tecniche anti-analysis e veicolazione multi-dispositivo rende la campagna particolarmente efficace contro target aziendali che operano in ambienti digitalizzati ma con margini di consapevolezza variabile sul phishing non convenzionale.
Inoltre, uno degli aspetti più insidiosi di questa campagna è la capacità degli attaccanti di bypassare efficacemente l’Email Security Gateway (ESG), ovvero quei sistemi preposti al filtraggio e alla protezione delle comunicazioni aziendali in ingresso.
Oltre a ciò, la campagna è arricchita da tecniche avanzate di fingerprinting e anti-analysis per evadere i controlli e rendere più difficile l’analisi da parte dei team SOC. Questo articolo mira ad analizzare le caratteristiche di questa campagna.
Perché bypassa i gateway?
Uno degli aspetti più insidiosi di questa campagna è la capacità di bypassare i filtri email esterni. Molti domini lasciano attivo il record MX di Microsoft 365 anche quando utilizzano un Email Security Gateway. L’attaccante può quindi eseguire una query MX e inviando la mail direttamente a Microsoft, aggirando quindi controlli dell’Email Security Gateway esterno.
Esempio:
telnet azienda-com.mail.protection.outlook.com 25
MAIL FROM: <spoofed@azienda.com>
RCPT TO: <utente@azienda.com>
DATA
Subject: Bonus Stipendio
…contenuto…
Un attaccante può usare un qualsiasi strumento per l’invio di mail, come banalmente telnet sulla porta 25 per connettersi direttamente al server MX di Microsoft 365 e inviare un’email spoofata simulando il mittente.
Questo consente di bypassare i gateway email esterni e sfruttare eventuali mancanze nella configurazione DMARC del dominio target.
Perché Microsoft 365 accetta queste mail?
Il comportamento di Microsoft 365, in realtà, è del tutto normale: come qualunque altro server di posta, è progettato per accettare email provenienti da Internet.
Per impostazione predefinita, Microsoft 365 non blocca le email in base all’indirizzo IP del mittente, e accetta tutto ciò che è tecnicamente conforme ai protocolli SMTP.
Accettare ≠ Consegnare in inbox.
Ricevere l’email non vuol dire che venga recapitata senza filtri. Verrà comunque sottoposta all’antispam di Microsoft e classificata.
Microsoft cosa fa?
Microsoft 365 non blocca automaticamente l’email che falliscono il controllo SPF. Questo comportamento può sorprendere, ma ha una motivazione precisa: Microsoft non considera SPF in maniera isolata, bensì lo valuta insieme ad altri fattori, come la firma DKIM, la policy DMARC impostata dal dominio mittente e la reputazione dell’IP o del dominio da cui proviene la mail.
In sostanza, Microsoft 365 prende in considerazione il risultato di SPF, ma decide se consegnare o filtrare il messaggio in base all’insieme dei segnali disponibili. Questo significa che una mail può fallire SPF ma essere comunque recapitata — ad esempio, se non esiste una policy DMARC restrittiva o se la reputazione del mittente è ritenuta accettabile.
Perché Microsoft non blocca direttamente?
Microsoft 365 non blocca automaticamente tutte le email che falliscono SPF perché un fallimento può verificarsi anche per motivi legittimi, ad esempio durante l’inoltro di email, se non viene mantenuta una firma DKIM valida.
Inoltre, Microsoft rispetta la policy DMARC del dominio mittente. Se questa non è impostata su reject (o manca del tutto), non c’è alcun obbligo formale di bloccare la mail, anche in caso di SPF o DKIM falliti.
Infine, Microsoft adotta un modello in cui la responsabilità della protezione del dominio è del mittente: se il dominio non ha configurato correttamente SPF, DKIM o DMARC, il sistema può comunque accettare la mail e valutarla secondo il contesto, lasciando la decisione finale a filtri aggiuntivi o policy locali.
Falsificazione Header SMTP
Alcuni attaccanti inseriscono header fasulli come se il messaggio fosse passato da un filtro legittimo. Esempio:
- X-Mimecast -Scan: Passed
- X-Mimecast -Spam-Score: 1.2/5.0
- X-Mimecast -Verdict: clean
Questo può trarre in inganno SIEM, regole antispam e operatori SOC. Può essere fatto con strumenti SMTP custom o script.
Esempio di script in python:
import smtplib
from email.message import EmailMessagemsg = EmailMessage()
msg[‘Subject’] = ‘Finta busta paga’
msg[‘From’] = ‘hr@azienda.it’
msg[‘To’] = ‘utente@target.it’
msg.add_header(‘X-Mimecast -Scan’, ‘Passed’)
msg.add_header(‘X-Mimecast -Verdict’, ‘clean’)
msg.set_content(‘Gentile utente, trova in allegato il cedolino.’)with smtplib.SMTP(‘smtp.attaccante.com’) as smtp:
smtp.send_message(msg)
Questa alterazione degli header ha un impatto limitato sulle policy automatiche di Microsoft, che si basano su controlli crittografici e reputazionali molto più robusti.
Tuttavia, può essere efficace nel trarre in inganno gli analisti umani, i sistemi SIEM o le regole antispam meno sofisticate, portando a una falsa sensazione di sicurezza e ritardando l’identificazione di email malevole.
Perché non filtrare solo le mail dai security gateway?
Ci si potrebbe chiedere: “Perché non si imposta Microsoft 365 per accettare email solo da Email Security Gateway e bloccare tutto il resto?”. In teoria sembra una buona idea, ma c’è un dettaglio tecnico importante.
Sulla carta è una strategia sensata, ma c’è un dettaglio tecnico cruciale che la complica: la posta interna. L’email inviate tra utenti della stessa organizzazione, se entrambe le caselle risiedono su Microsoft 365, non transitano da Internet né tantomeno da ESG esterni. Viaggiano interamente all’interno del cloud Microsoft.
Imporre un blocco su tutte le email che non passano dall’ESG significherebbe interrompere anche il flusso interno, con effetti disastrosi sulla comunicazione aziendale. Un classico caso in cui il rimedio rischia di fare più danni del problema.
Quindi, che contromisure adottare per fermare una campagna che si muove sotto il radar dei filtri?
— Lo vediamo nelle conclusioni 😉
Com’è fatta l’email?
Lo so, mi sono forse dilungato un po’ troppo sul funzionamento del bypass dei gateway email, ma quando una tecnica così semplice riesce a eludere controlli progettati per bloccare attacchi ben più complessi, vale la pena prendersi un momento.
Ora, arriviamo a ciò che più ci interessa: com’è fatta questa mail malevola? Come inizia la campagna?
La campagna inizia con una email apparentemente inviata dallo stesso utente destinatario (spoofing). Il messaggio contiene un QR code, integrato direttamente nel corpo dell’email o come allegato PDF.
La comunicazione fa leva su messaggi generici ma credibili, spesso legati a tematiche sensibili per l’utente aziendale, come: “Disponibile l’aggiornamento del bonus in busta paga.”
Utilizzando contenuti legati alla sfera economica o lavorativa, l’attaccante spinge l’utente ad agire impulsivamente.
Esempio di QR presente nel PDF:
Una volta scansionato, il QR code reindirizza a un dominio controllato dall’attaccante. La destinazione può variare: da pagine di phishing che simulano portali aziendali o form di login, a contenuti malevoli progettati per infettare il dispositivo, soprattutto se la scansione avviene da mobile.
Nascondersi all’analisi
Per ostacolare l’analisi e rendere più complessa la rilevazione da parte di strumenti automatici o analisti della sicurezza, il sito di destinazione, raggiunto tramite il QR code, adotta una serie di tecniche avanzate di evasione e anti-analysis. Queste soluzioni mirano a impedire l’ispezione del codice, l’interazione manuale e l’utilizzo di strumenti comunemente impiegati durante le attività di analisi. Tra le contromisure adottate, si osservano:
- Rilevamento di ambienti quali: Burp Suite, PhantomJS, WebDriver
- Disabilitazione shortcut (F12, Ctrl+Shift+I, Ctrl+U…)
- Blocco del menu contestuale (click destro)
- Misurazione del tempo di esecuzione per rilevare debugger via `performance.now()`
Se rilevata analisi → redirect a sito legittimo (es. target.com) per mascherare il contenuto reale.
Rilevamento Anti-Automation e Anti-Proxy
Questo frammento di codice identifica ambienti automatizzati e strumenti di proxy come Burp Suite:
Lo script controlla se la pagina è caricata in ambienti headless o strumentati, come Selenium WebDriver, PhantomJS o proxy come Burp Suite. In caso positivo, la pagina viene immediatamente oscurata o bloccata (window.location = “about:blank”).
Non si sbircia
Come possiamo osservare, la pagina web è progettata per ostacolare l’analisi manuale, disabilitando diverse combinazioni di tasti comunemente utilizzate per ispezionare il codice o il comportamento della pagina. In particolare, vengono bloccati:
- F12 (DevTools)
- Ctrl+U (sorgente pagina)
- Ctrl+Shift+I / C / J (console, ispezione, debugger)
- Ctrl+H, Meta+Alt+I/C (altri shortcut su Mac)
L’obiettivo di queste restrizioni è impedire che l’utente – o un analista di sicurezza – possa interagire con il DOM, esaminare gli script attivi o identificare eventuali indicatori di compromissione all’interno della pagina. Si tratta di una tecnica comune nei siti malevoli per rendere più difficile l’attività di reverse engineering e rallentare l’individuazione della truffa.
Blocco click destro
Intercetta l’evento contextmenu (click destro del mouse) e lo blocca, impedendo all’utente di:
- ispezionare elementi
- salvare immagini, codice QR o HTML
- accedere a funzioni browser avanzate
Anti-debugging con performance.now
Una delle tecniche di rilevamento del debugging più comuni in tempo reale consiste nell’utilizzo della funzione performance.now() per misurare eventuali ritardi nell’esecuzione del codice.
Il meccanismo funziona così:
- Viene eseguita una chiamata a performance.now() prima di un’istruzione debugger;
- Subito dopo la riga debugger, viene effettuata una seconda chiamata a performance.now()
- Se i DevTools del browser sono aperti con i breakpoint attivi, l’esecuzione del codice si interrompe alla riga debugger;
Di conseguenza, l’intervallo di tempo tra le due chiamate a performance.now() risulterà anormalmente elevato (tipicamente superiore ai 100 ms).
Questo comportamento viene interpretato come un segnale che l’utente sta analizzando il sito o tentando di ispezionarne il funzionamento.
Infine il sito malevolo reindirizza automaticamente l’utente verso una pagina web legittima (es. target.com), nel tentativo di mascherare le proprie vere intenzioni e confondere analisti o strumenti automatici.
Se lo scansiono da smartphone?
Dopo che l’utente scansiona il codice QR, viene automaticamente indirizzato a un link che apre una falsa schermata di login Microsoft, progettata con cura per imitare fedelmente l’aspetto e il layout della pagina ufficiale.
Questa schermata è precompilata con il nome dell’utente, che viene passato come parametro all’interno dell’URL contenuto nel codice QR stesso.
Questa tecnica aumenta significativamente la credibilità del sito fasullo, poiché l’utente vede il proprio nome già inserito, il che suggerisce implicitamente che la pagina sia autentica e personalizzata.
L’obiettivo finale degli attaccanti è quello di convincere l’utente a inserire le proprie credenziali direttamente nella pagina web falsa, ingannandolo nel pensare che stia effettuando il login sulla piattaforma Microsoft ufficiale.
Questa fase rappresenta il fulcro dell’attacco di quishing, in quanto permette agli aggressori di catturare username e password, sfruttando la fiducia e la disattenzione dell’utente.
In conclusione
La campagna di quishing analizzata mette in luce come gli attaccanti non si limitino a sfruttare la naturale fiducia negli QR code, ma adottino tecniche avanzate per bypassare i sistemi di sicurezza più comuni.
Questa combinazione di ingegnosità tecnica e manipolazione psicologica rende gli attacchi di quishing particolarmente pericolosi e difficili da rilevare. Tuttavia, nonostante l’importanza di strategie multi-livello e sistemi di protezione aggiornati, la componente più fondamentale nella difesa contro le frodi informatiche resta la consapevolezza degli utenti.
Senza una solida awareness, anche le migliori tecnologie possono risultare inefficaci, poiché gli attaccanti puntano proprio sulla manipolazione psicologica e sull’errore umano per avere successo. Per questo motivo, la formazione continua e l’educazione degli utenti rappresentano la prima linea di difesa, da integrare necessariamente con soluzioni tecnologiche e una governance attenta.
Solo un approccio integrato, che ponga l’awareness al centro e la supporti con strumenti tecnologici e processi di sicurezza ben strutturati, può davvero contrastare queste minacce sofisticate e tutelare efficacemente le infrastrutture digitali aziendali e personali.
Di Francesco Cappiello – Cyber Security Analyst L3, CYBEROO
