Campagna di phishing si nasconde dietro reindirizzamenti Google a più passaggi per sottrarre credenziali

I servizi Google affidabili formano una catena d’attacco in tre passaggi

Una campagna di phishing tuttora in corso indirizza le vittime attraverso diversi servizi Google legittimi prima di mostrare pagine per la raccolta di credenziali o software di accesso remoto.

I ricercatori di KnowBe4 Prabhakaran Ravichandhiran e Jeewan Singh Jalal hanno descritto l’attività il 4 settembre. L’operazione utilizza una catena di reindirizzamenti in tre passaggi, progettata per ostacolare i gateway di sicurezza della posta elettronica, gli scanner degli URL e i sistemi di ispezione automatica.

Anziché inserire direttamente in un’email malevola un indirizzo controllato dagli aggressori, gli operatori integrano servizi come Google Meet, l’infrastruttura pubblicitaria DoubleClick, Google Custom Search, Google Image Search, Google Tag Manager e Google Analytics.

Ogni reindirizzamento espone i prodotti di sicurezza a un altro dominio affidabile gestito da Google. Un gateway che attribuisce un peso elevato alla reputazione del dominio potrebbe quindi considerare benigno il collegamento, soprattutto se non segue l’intera catena o non analizza la pagina finale in un browser reale.

La tecnica è più sofisticata del semplice accorciamento o occultamento di un URL malevolo. L’infrastruttura è progettata per rimanere plausibile durante le successive fasi di ispezione, mentre la destinazione può ritardare o modificare il proprio comportamento fino al termine dei controlli automatici.

Al momento della pubblicazione, Google non aveva commentato la campagna segnalata.

I frammenti degli URL nascondono i dati per il targeting delle vittime

Uno dei segnali più evidenti per rilevare l’operazione è l’inserimento dell’indirizzo email del destinatario nel frammento dell’URL, cioè nella parte successiva al carattere #. L’indirizzo viene codificato con Base64 e utilizzato per personalizzare la destinazione.

Una struttura semplificata potrebbe essere simile alla seguente:

https://legitimate-service.example/path#BASE64_ENCODED_EMAIL

Il frammento offre agli aggressori una caratteristica utile: in genere i browser non lo includono nella richiesta HTTP inviata a un server web. Il frammento rimane disponibile a JavaScript lato client, ma potrebbe non comparire nei log di accesso del server né negli strumenti di sicurezza che registrano soltanto la risorsa richiesta.

Una volta caricata la pagina finale, il relativo JavaScript può leggere il frammento, decodificare l’indirizzo email e creare un’esperienza di phishing personalizzata. La pagina può precompilare l’identità della vittima e mostrare un’immagine del sito web autentico dell’organizzazione dietro un’interfaccia di accesso contraffatta.

Questo comporta due vantaggi. Innanzitutto, la vittima visualizza una pagina apparentemente collegata al proprio datore di lavoro, anziché una richiesta generica di credenziali. Inoltre, alcuni dati di telemetria di rete e lato server potrebbero registrare la destinazione del reindirizzamento senza conservare l’indirizzo email preso di mira.

Base64 è una codifica, non una cifratura. Un prodotto di sicurezza che acquisisce l’URL completo può decodificarla facilmente. Il problema è capire se quel prodotto conserva e analizza effettivamente il frammento.

La presenza di un indirizzo email codificato dopo #, soprattutto in un messaggio che passa attraverso l’infrastruttura Google, dovrebbe quindi essere considerata un indizio di grande valore per il rilevamento. Non dimostra che ogni URL di questo tipo sia malevolo, ma offre ai difensori uno schema circoscritto da analizzare.

La destinazione si adatta alla vittima e all’ambiente di ispezione

Le email malevole utilizzano diversi pretesti legati all’attività aziendale, anziché un unico modello coerente. Tra i temi osservati figurano la revisione di documenti, le credenziali in scadenza, le consegne di pacchi, i pagamenti, i sussidi pubblici e le notifiche di messaggi vocali.

Dopo il clic del destinatario, i reindirizzamenti conducono infine a uno di due esiti principali. Il primo è una pagina di autenticazione aziendale contraffatta, progettata per raccogliere nomi utente e password. Il secondo è un processo fraudolento di verifica dell’identità che tenta di installare ScreenConnect.

In questo caso ScreenConnect viene utilizzato come strumento di accesso remoto, non come meccanismo alla base dei reindirizzamenti. Non sono state rese note le versioni specifiche di ScreenConnect coinvolte e la campagna non viene descritta come lo sfruttamento di una vulnerabilità del software. Il pericolo deriva dalla capacità di convincere l’utente a installare o eseguire software di amministrazione remota non autorizzato.

Il framework di phishing può modificare i contenuti in base alla posizione geografica della vittima e supporta più lingue. Raccoglie inoltre informazioni contestuali che possono aiutare gli operatori a valutare sia il bersaglio sia la sessione compromessa.

Secondo quanto riportato, i dati esposti includono:

• Credenziali di accesso aziendali
• Indirizzi IP pubblici
• Informazioni di geolocalizzazione
• Stringhe user-agent del browser
• Record di scambio della posta verificati associati all’organizzazione della vittima
• Dati sul targeting dell’organizzazione e sulla sessione

Le credenziali sottratte e i metadati raccolti vengono trasmessi agli operatori attraverso un canale Telegram, secondo quanto riferito nel giro di pochi secondi. Telegram offre un comodo livello di comunicazione che può confondersi con altro traffico di messaggistica cifrata, a meno che i difensori non monitorino in modo specifico l’attività dei bot e delle API.

La campagna combina quindi personalizzazione, elusione ed esfiltrazione rapida. Un’interazione riuscita può portare alla compromissione dell’account, mentre un’installazione non autorizzata di ScreenConnect può offrire un percorso verso l’amministrazione remota diretta.

Perché la sola reputazione del dominio non basta contro questa tecnica

Molti sistemi di controllo della posta elettronica e del web analizzano il nome host visibile di un collegamento, interrogano i servizi di reputazione e seguono un numero limitato di reindirizzamenti. Questo approccio diventa meno efficace quando gli aggressori possono assemblare una catena composta da servizi cloud e componenti pubblicitari legittimi.

Bloccare indiscriminatamente i domini Google provocherebbe notevoli disservizi operativi. Gli aggressori traggono vantaggio proprio da questo vincolo: i difensori devono distinguere l’uso malevolo da grandi volumi di traffico aziendale ordinario, anziché negare del tutto l’accesso all’infrastruttura.

Uno scanner potrebbe inoltre osservare un comportamento diverso da quello mostrato a un visitatore umano. Il sistema finale di raccolta delle credenziali può attendere la conclusione dell’ispezione, valutare segnali dell’ambiente o modificare la risposta in base alla posizione e alle caratteristiche della sessione. Un risultato pulito ottenuto da una richiesta automatica non garantisce che l’utente riceva la stessa pagina.

I controlli dovrebbero quindi valutare l’intero percorso di navigazione, includendo:

1. L’URL originale incorporato nell’email
2. Ogni reindirizzamento intermedio e i relativi parametri
3. Il dominio registrato finale e la posizione dell’hosting
4. Gli script lato client eseguiti dopo il caricamento della pagina
5. I frammenti degli URL conservati nel messaggio originale
6. I download successivi, i moduli di accesso o le richieste di installazione di strumenti di accesso remoto
7. Le comunicazioni in uscita avviate dopo l’interazione dell’utente

Questa campagna non dipende da un singolo prodotto Google compromesso né da una versione vulnerabile resa nota. Sfrutta i rapporti di fiducia tra diversi servizi e le lacune esistenti tra la telemetria della posta elettronica, dei proxy, dei browser, degli endpoint e dei sistemi di identità.

I difensori dovrebbero cercare traffico Telegram e attività di ScreenConnect

Le organizzazioni dovrebbero applicare gli indicatori di compromissione pubblicati ai sistemi di filtraggio DNS, ai gateway web sicuri, ai proxy, agli endpoint e alle piattaforme SIEM. Un blocco applicato a un solo livello potrebbe non rilevare le fasi successive della catena di reindirizzamento.

I team di sicurezza dovrebbero inoltre cercare connessioni in uscita verso Telegram Bot API e altre comunicazioni insolite legate a Telegram. Questo traffico merita ulteriori verifiche quando segue il clic su un’email sospetta, la visita a una pagina di autenticazione sconosciuta o l’esecuzione di un nuovo processo.

La ricerca sugli endpoint dovrebbe concentrarsi sulle installazioni e sulle attività di ScreenConnect non autorizzate. I controlli pertinenti includono eventi di installazione inattesi, servizi appena creati, esecuzioni da directory scrivibili dall’utente e sessioni di accesso remoto che non corrispondono a un flusso di assistenza approvato. Le distribuzioni legittime dell’organizzazione devono essere distinte dalle istanze non autorizzate.

Agli utenti potenzialmente coinvolti dovrebbe essere richiesto di reimpostare le password. I difensori dovrebbero inoltre esaminare i record di autenticazione alla ricerca di posizioni e dispositivi insoliti, della creazione di sessioni, di modifiche all’autenticazione a più fattori e di accessi avvenuti poco dopo la consegna del messaggio di phishing.

Tra le azioni difensive utili figurano:

• Conservare gli URL completi, incluso il contenuto successivo al carattere #, nei dati di telemetria per l’analisi della posta elettronica.
• Decodificare i frammenti Base64 durante l’ispezione dei messaggi e degli URL.
• Seguire tutti i reindirizzamenti invece di valutare soltanto il primo hostname Google.
• Correlare i reindirizzamenti verso servizi Google con la comparsa di nuovi moduli di accesso.
• Cercare download, installazioni o esecuzioni successive di ScreenConnect.
• Monitorare il traffico verso Telegram Bot API come possibile canale di esfiltrazione.
• Avvisare gli utenti che la presenza di domini cloud familiari non garantisce una destinazione sicura.
• Analizzare i messaggi che utilizzano temi legati a documenti, consegne, pagamenti, messaggi vocali, sussidi o scadenza delle credenziali.

La sensibilizzazione degli utenti dovrebbe concentrarsi sui comportamenti, non sul marchio. Un collegamento può iniziare su un servizio Google legittimo e terminare comunque su una pagina controllata dagli aggressori. Le richieste di autenticazione inattese e le verifiche dell’identità che richiedono software di accesso remoto dovrebbero essere segnalate, non completate.

L’elemento distintivo di questa campagna non è un singolo pretesto di phishing. È l’uso coordinato di un’infrastruttura di reindirizzamento affidabile, dati di targeting nascosti, contenuti web adattivi ed esfiltrazione quasi in tempo reale per far apparire come ordinario un attacco personalizzato.