MFA e supply chain diventano trappole tra TrustSink e Brevo ClickFix

🛡️ Executive Summary

• TrustSink permette a un attaccante già dotato di elevati privilegi Microsoft Entra di registrare un provider MFA esterno malevolo e sottrarre password dentro un login apparentemente legittimo.
• Il cambio password non elimina il problema: finché il provider rogue rimane configurato, può catturare anche la nuova credenziale al login successivo.
• Brevo ha invece subito la compromissione di una chiave API Cloudflare con privilegi completi, usata per modificare al CDN edge JavaScript incorporato anche sui siti dei clienti e distribuire ClickFix e un backdoor plugin WordPress.

Due incidenti molto diversi mostrano lo stesso problema strutturale: una catena di sicurezza può diventare vulnerabile proprio nel punto al quale è stata delegata la fiducia. TrustSink non rompe la crittografia dell’MFA e non aggira Microsoft Entra dall’esterno: trasforma un provider di autenticazione esterno autorizzato in una pagina capace di raccogliere password durante un login che continua a completarsi normalmente. Nel caso Brevo, invece, gli attaccanti non hanno modificato i server origin dell’azienda: hanno ottenuto una chiave Cloudflare e usato il livello CDN per alterare JavaScript affidabile già incorporato nei siti dei clienti. In entrambi i casi l’attaccante non costruisce una copia convincente del servizio: riesce a entrare nella catena considerata legittima.

TrustSink inserisce il phishing dentro il flusso MFA legittimo

Varonis Threat Labs ha chiamato TrustSink una tecnica che sfrutta gli External Authentication Methods di Microsoft Entra. Le organizzazioni possono configurare provider MFA esterni: dopo il primo fattore, Entra trasferisce l’utente al servizio terzo, che completa il controllo e restituisce un token firmato attestando il successo dell’autenticazione. È questa delega a creare la superficie abusabile.

Un attaccante che controlla già un account con privilegi elevati può registrare un External Authentication Method malevolo. Quando l’utente effettua un normale login Microsoft, inserisce inizialmente la propria password sul dominio legittimo; al momento del secondo fattore viene però reindirizzato al provider rogue, che invece della verifica MFA presenta una pagina praticamente identica a quella Microsoft chiedendo nuovamente la password.

Se la vittima la inserisce, la credenziale viene acquisita in chiaro dal server dell’attaccante. Il provider malevolo può quindi restituire a Entra un token firmato che dichiara completato il secondo fattore e lasciare proseguire normalmente l’accesso. L’assenza di errore è precisamente ciò che rende la tecnica pericolosa: dal punto di vista dell’utente non c’è necessariamente un login fallito che faccia scattare il sospetto.

Il meccanismo sfrutta quindi quella stessa fiducia nell’ambiente autenticato già abusata da campagne di phishing capaci di utilizzare servizi Google legittimi per sottrarre credenziali: il problema non è più convincere l’utente a visitare un dominio palesemente estraneo, ma spostare l’inganno dentro un percorso nel quale l’utente si aspetta realmente una richiesta di autenticazione.

Leggi anche: Il phishing sfrutta servizi Google legittimi per rubare credenziali

Cambiare la password non basta se il provider malevolo resta configurato

TrustSink non è una tecnica di initial access. Per registrare il provider esterno occorre già possedere privilegi importanti nel tenant, come quelli associati a Global Administrator o Authentication Policy Administrator, oltre alla possibilità di modificare la Authentication Methods Policy e predisporre applicazione, service principal e consent necessari. Questo delimita correttamente il rischio: un aggressore Internet casuale non può semplicemente attivare TrustSink contro qualsiasi organizzazione Microsoft 365. Dopo una compromissione privilegiata, però, il valore della tecnica aumenta perché il provider rimane nella catena di autenticazione. Nei test di Varonis, anche il reset della password non interrompeva la raccolta: al login successivo il provider malevolo chiedeva nuovamente la credenziale e catturava quella appena sostituita.

L’ordine della remediation diventa quindi essenziale. Bisogna prima rimuovere l’External Authentication Method sospetto, applicazioni associate, chiavi e redirect URI e soltanto successivamente ruotare le password. Altrimenti l’organizzazione può completare una procedura di credential reset formalmente corretta e riconsegnare immediatamente la nuova password all’attaccante. Varonis raccomanda inoltre di monitorare le modifiche alla Authentication Methods Policy, ridurre i privilegi amministrativi permanenti e preferire fattori phishing-resistant come FIDO2 e Windows Hello for Business.

Brevo viene compromessa attraverso una chiave Cloudflare nel codice

Il caso Brevo sposta la stessa logica dal piano dell’identità alla software supply chain. Il 14 settembre 2026 un attaccante ha utilizzato una chiave API Cloudflare compromessa per creare un Worker malevolo nell’account della società e modificare le risposte HTTP direttamente al CDN edge. Brevo indica una finestra d’impatto dalle 15:01 alle 20:30 UTC, circa cinque ore e mezza. La causa primaria individuata nel post-mortem è particolarmente grave: una API key Cloudflare long-lived con privilegi completi era conservata nel source code dell’applicazione. Una volta acquisita, permetteva di creare Workers, route e record DNS nelle zone Brevo senza generare l’allarme necessario. Gli origin server e i file originali non dovevano essere modificati perché il contenuto poteva essere riscritto durante il transito attraverso il CDN. L’attaccante ha inoltre rimosso header di sicurezza come Content-Security-Policy, riducendo la capacità dei browser di bloccare il codice iniettato. È un dettaglio cruciale: i normali controlli di integrità sull’applicazione origin potevano continuare a vedere file corretti mentre ai visitatori veniva consegnata una versione differente.

Gli script Brevo trasformano i siti dei clienti in una rete di distribuzione

L’impatto ha superato i siti direttamente gestiti da Brevo perché sono stati modificati anche tre file JavaScript incorporabili dai clienti, compresi form, Conversations widget e SDK loader. Sansec stima che i componenti Brevo fossero presenti su oltre 100.000 siti, trasformando una singola credenziale cloud compromessa in una superficie supply-chain estremamente più ampia. Brevo conferma l’alterazione degli script embedded, mentre la stima sulla portata complessiva proviene dall’analisi indipendente di Sansec. I visitatori selezionati vedevano una falsa pagina Cloudflare di verifica che chiedeva di premere Win+R, Ctrl+V e Invio, schema ormai caratteristico delle campagne ClickFix: la vittima viene convinta a eseguire volontariamente un comando locale invece di ricevere un exploit browser automatico. Sui siti WordPress la catena diventava ancora più aggressiva. Quando lo script rilevava un amministratore autenticato, tentava di installare un plugin malevolo chiamato Web Media Optimizer. L’analisi recuperata da BleepingComputer mostra che il plugin poteva nascondersi dalla normale lista, copiarsi tra i must-use plugin, mantenere un loader JavaScript persistente e includere una chiave capace di consentire la creazione di una sessione amministrativa valida senza conoscere la password dell’account. È il genere di rischio che rende particolarmente sensibile l’automazione degli aggiornamenti e dei componenti WordPress quando la fiducia viene trasferita a codice distribuito da terzi: il sito può essere perfettamente aggiornato e continuare a servire codice malevolo perché il componente compromesso arriva dalla supply chain esterna.

Il CDN ha permesso di modificare il risultato senza toccare l’origine

La parte tecnicamente più interessante dell’incidente Brevo è proprio la separazione tra origine e ciò che riceve l’utente. Il modello tradizionale di integrity monitoring controlla file, repository, build e server. Qui l’attaccante aveva invece acquisito la possibilità di intervenire dopo l’origine, attraverso il Worker Cloudflare. Il risultato è un problema di trust boundary: brevo.com, sibforms.com e gli URL JavaScript restavano domini legittimi e i server applicativi potevano restare immutati, ma il contenuto finale non era più quello generato dall’applicazione. Brevo afferma di aver revocato la chiave compromessa e le credenziali create attraverso di essa, rimosso Worker e route malevoli, eliminato gli hostname dell’attaccante e svuotato le cache edge. L’azienda precisa inoltre di non aver trovato iniezioni precedenti al 14 settembre, pur indicando che la chiave risultava già abusata dalla fine di agosto. Per gli amministratori WordPress che hanno visitato un sito interessato mentre erano autenticati, la verifica deve quindi andare oltre la scomparsa della pagina ClickFix: bisogna controllare plugin installati o attivati il 14 settembre, eventuali componenti must-use anomali e procedere alla rotazione delle credenziali quando emergono indicatori compatibili.

Continua con:

WordPress automatizza la revisione dei plugin ma la supply chain resta il punto critico

Attacchi a cPanel e infrastrutture Internet-facing mostrano il valore dei componenti condivisi

Il problema comune è chi può parlare a nome di un sistema fidato

TrustSink e Brevo non condividono malware, infrastruttura o tecnica iniziale. Condividono però un modello di rischio che diventa sempre più centrale: la compromissione del soggetto al quale il sistema principale ha concesso il diritto di attestare o modificare qualcosa. Microsoft Entra si fida del provider MFA configurato quando afferma che il secondo fattore è stato completato. Il browser si fida del JavaScript servito da un dominio Brevo che il sito ha deliberatamente incorporato. Brevo, a sua volta, si fidava di una chiave Cloudflare dotata di privilegi sufficienti a modificare le risposte distribuite dai propri domini. Per questo l’MFA non diventa improvvisamente inutile e i CDN non diventano intrinsecamente insicuri. Il punto è diverso: aggiungere un livello di sicurezza o un servizio esterno significa anche creare una nuova relazione di fiducia che deve essere monitorata, limitata e revocabile. Il least privilege non riguarda più soltanto utenti e processi. Deve raggiungere provider MFA, API key, Workers, script embedded, service principal e ogni componente al quale viene consentito di agire come parte legittima dell’infrastruttura.