L'abuso dei reindirizzamenti di Google favorisce il phishing e l'invio di spam

5 agosto 2026

Panoramica sulle minacce

L'abuso dei reindirizzamenti di Google è una tecnica molto diffusa in cui gli autori delle minacce sfruttano i servizi legittimi di reindirizzamento degli URL di Google per mascherare link dannosi, aggirare le difese di sicurezza della posta elettronica e aumentare la percezione di legittimità delle campagne di phishing e spam. Gli autori degli attacchi sfruttano la reputazione affidabile del dominio di Google in modo che i link sembrino puntare a google.com (o ad altre proprietà di Google), reindirizzando però gli utenti verso pagine volte al furto di credenziali, malware o contenuti indesiderati.

Poiché questi reindirizzamenti provengono dall’autentica infrastruttura di Google, spesso superano i controlli sulla reputazione del dominio, le politiche di riscrittura degli URL e l’esame da parte degli utenti. Gli addetti alla sicurezza che si affidano a liste di autorizzazione contenenti *.google.com o che considerano gli URL di Google intrinsecamente sicuri rimangono esposti a questa categoria di abusi.

 Mimecast Threat Research continua a osservare le tecniche di reindirizzamento di Google nell’ambito della raccolta di credenziali e dello spam ad alto volume. Le sezioni seguenti documentano le principali famiglie di reindirizzamenti, la loro struttura URL e il comportamento di elusione.

 Famiglie di reindirizzamenti

1. Google Web Light

Google Web Light era un servizio di transcodifica che forniva versioni più leggere e veloci delle pagine web agli utenti con connessioni mobili lente (ad esempio 2G), principalmente in paesi come India, Brasile e Indonesia. Utilizzava il dominio googleweblight.com e le risorse a livello di percorso sp e i per recuperare e reindirizzare a un URL di destinazione passato nel parametro u.

Google ha dismesso Web Light il 19 dicembre 2022 e ha rimosso la documentazione pubblica, ma il dominio e il comportamento di reindirizzamento rimangono accessibili e vengono ancora utilizzati in modo improprio in campagne malevole.

URL di esempio

 https://googleweblight.com/sp?otherkeys=othervals&u=https://7d63dd4a.ryhryhyj6j56h6t4635.pages.dev?ut=name@domain.com

2. Reindirizzamento URL principale: `google.*/url`

Il meccanismo principale è il reindirizzamento aperto su percorsi come /url su vari host di Google.

Cercare google./url? con un parametro q= contenente un URL. Qualsiasi host che serva questo percorso può reindirizzare verso una destinazione arbitraria.

URL di esempio

https://www.google.com/url?q=https://malicious-site.com&sa=D&sntz=1

Parametri tipici

3. Abusi relativi a Google AMP (Accelerated Mobile Pages)

Google AMP è un framework HTML open source utilizzato per creare siti web ottimizzati per i browser e l’uso su dispositivi mobili. Poiché AMP è in grado di visualizzare i contenuti delle pagine web in linea, gli autori delle minacce ne abusano ora per presentare pagine di phishing in tempo reale dopo che l’utente ha cliccato su un link.

Abuso di AMP autonomo

AMP legittimo:

https://google.com/amp/s/domain.com/path

Forma abusiva (omissione della "s"):

https://google.com/amp/domain.com

Questa variante è relativamente rara nel traffico innocuo, ma compare in diverse campagne malevole. Spesso è associata ad altri indicatori di phishing, piuttosto che essere utilizzata come unico segnale di blocco.

Gli autori degli attacchi incorporano URL Google AMP nelle e-mail (ad esempio ...&url=amp/malicious-site.com). Quando il parametro "q" viene modificato, la destinazione finale può essere alterata mentre l'URL passa comunque attraverso Google, quindi il link visibile rimane un URL di Google.

Esempio di pattern

https://www.google.co.uk/url?q=...&rct=...&sa=t&url=amp/mimecast.com

Modificando l’ultimo percorso in url=amp/... è possibile reindirizzare a un sito arbitrario; la rimozione di /amp spesso fa apparire la pagina di avviso interstiziale di Google.

Questo servizio è molto tollerante nella formattazione degli URL e normalizza un’ampia gamma di formattazioni errate, consentendo agli autori delle minacce di aggirare i limiti di visibilità esistenti modificando gli URL in modi inaspettati.

4. Google Travel: `/travel/clk`

Questo reindirizzamento aperto è correlato al servizio Google Travel, disponibile su tutti gli hostname di Google. Indirizza il traffico verso siti esterni attraverso il prodotto Google Travel. Si tratta di un reindirizzamento aperto parzialmente contenuto: è richiesto un token generato dal sistema, ma non limita la destinazione del reindirizzamento. Tale token può essere generato tramite Google Travel su richiesta e non impedisce la modifica della destinazione.

URL di esempio

https://www.google.com/travel/clk?pc=AA80Osz1Y9jFF8K4dj7wcdCsT2otn5mxfNX82xi-cd4&pcurl=https://malicious-site.com

5. Host Google non standard (ccTLD e sottodomini di servizio)

Stessa struttura del reindirizzamento URL principale; cambia solo il nome host.

Gli autori degli attacchi utilizzano lo stesso schema /url?q= (o equivalente) su host diversi da www.google.com, ad esempio google.es, google.de, google.fr, maps.google.*, contacts.google.* e drive.google.*. Si tratta di proprietà legittime di Google, ma sono meno spesso incluse nelle regole specifiche per i reindirizzamenti.

Domini con codice paese (ccTLD)

Gli autori degli attacchi utilizzano i ccTLD di Google meno monitorati in modo che le liste di autorizzazione basate sui domini e i controlli di reputazione continuino a rilevare "Google", riducendo al contempo la copertura delle regole personalizzate.

Esempi:

https://google.es/url?q=http://bad-domain.com
https://google.de/url?...
https://google.fr/url?...

Sottodomini di servizio

L'abuso dei reindirizzamenti si riscontra anche su sottodomini non comunemente associati ai reindirizzamenti dei link, aumentando il numero di modelli che i difensori devono gestire:

Questi sono visibili anche come parte di catene di reindirizzamento provenienti da altri siti:

URL di origine → reindirizzamento di Google (con &sa=D&sntz=1&usg=) → valore url?q=

6. Google Meet/Hangouts e App Engine

(1) Meet

Percorso meet.google.com/linkredirect con il parametro di query dest= contenente l’URL di destinazione. In precedenza, anche Google Hangouts seguiva un percorso simile per il reindirizzamento.
https://meet.google.com/linkredirect?dest=https://malicious-site.com

(2) App Engine

Percorso appengine.google.com/_ah/logout con continue= che punta a un altro URL (spesso Hangouts o il sito finale). Nelle e-mail, le catene che combinano entrambi costituiscono un forte segnale di abuso.

Esempio di reindirizzamenti a catena

https://www.google.com/url?sa=D&q=https://appengine.google.com/_ah/logout?continue=https://hangouts.google.com/linkredirect?dest=https://www.vizor.cloud/...

Tali catene (disconnessione da App Engine → Hangouts → destinazione finale) non hanno alcun uso legittimo comune nelle e-mail e sono soggette a blocco con un elevato grado di affidabilità.

7. Google DoubleClick / Servizi pubblicitari

I prodotti di analisi dei link di marketing di Google espongono reindirizzamenti aperti su googleadservices.com e doubleclick.net. A differenza dei reindirizzamenti /url di Google Search, questi non sono pubblicamente documentati come protetti contro gli abusi e hanno registrato un aumento degli usi impropri. Gli aggressori in genere prelevano link pubblicitari validi e modificano solo la destinazione adurl, spesso concatenando ulteriori reindirizzamenti e conservando frammenti di query (ad esempio l’indirizzo e-mail del destinatario) per personalizzare le pagine di phishing.

(1)doubleclick.net

URL di esempio

https://adclick.g.doubleclick.net/pcs/click?xai=...&sig=...&urlfix=1&adurl=https://wikipedia.org

(2) googleadservices.com

URL di esempio

https://www.googleadservices.com/pagead/aclk?sa=L&ai=...&sig=...&adurl=https://wikipedia.org

8. Google Translate

translate.goog viene utilizzato in modo improprio codificando il dominio di phishing nel nome host.

URL di esempio

https://phishing-com.translate.goog/?_x_tr_sl=auto&_x_tr_tl=en

(Una volta decodificato, l'host di destinazione risulta essere phishing.com.)

I nomi host assumono la forma *..translate.goog, dove il sottodominio è il dominio di destinazione con i punti sostituiti da trattini (ad esempio example.com → example-com.translate.goog). Possono essere presenti parametri quali _x_tr_sl=auto e _x_tr_tl=en. È meno probabile che i filtri di sicurezza li segnalino poiché appaiono come domini Google legittimi.

Schema di costruzione

1. Sostituire i punti nel dominio di destinazione con trattini (ad esempio example.com → example-com)
2. Utilizzare come sottodominio di translate.goog: https://example-com.translate.goog
3. I parametri opzionali come _x_tr_sl=auto, _x_tr_tl=en fanno sembrare l’URL un normale link di Translate

9. Reindirizzamento OAuth di Google

Google OAuth 2.0 è un framework di autorizzazione standard del settore progettato per consentire un accesso sicuro e delegato agli account degli utenti senza richiedere la condivisione della password. Il sistema consente alle applicazioni di terze parti di richiedere autorizzazioni limitate e circoscritte per accedere ai dati degli utenti (e-mail, profilo, calendario e così via) attraverso un processo di consenso controllato dall'utente.

I flussi di autorizzazione di Google OAuth 2.0 utilizzano un reindirizzamento per riportare l’utente all’applicazione dopo il consenso. Il parametro redirect_uri indica a Google dove inviare l’utente (insieme al codice di autorizzazione o al token). Se un malintenzionato riesce a controllare o influenzare questo valore, può rubare codici di autorizzazione o token oppure reindirizzare gli utenti verso una pagina di phishing dopo un accesso a Google apparentemente legittimo.

URL di esempio (richiesta di autorizzazione)

https://accounts.google.com/o/oauth2/v2/auth?client_id=123456789.apps.googleusercontent.com&redirect_uri=https://attacker.com/callback&response_type=code&scope=openid%20email%20profile&state=random_state

Tecniche di elusione

Poiché il token usg è legato alla stringa di query, gli aggressori non possono modificare liberamente i parametri di query per trasmettere dati specifici dell’utente senza invalidare il reindirizzamento. Gli aggressori utilizzano quindi i frammenti di URL per il tracciamento, la compilazione automatica dei moduli o il passaggio di token alla pagina finale senza interrompere il reindirizzamento di Google.

I frammenti di URL (la parte dopo #):

• Non vengono inviati al server
• Non sono inclusi nella convalida usg
• Vengono conservati dal browser durante il reindirizzamento

Esempio

https://google.es/url?q=http://malicious-site.com&usg=...#user123

Ulteriori modelli di elusione:

Protezione Mimecast

Mimecast ha identificato gli attributi associati all’abuso dei reindirizzamenti di Google attraverso l’analisi dei link nelle e-mail, l’ispezione della riscrittura degli URL e la valutazione delle catene di reindirizzamento post-clic. La copertura del rilevamento comprende:

• Reindirizzamenti Core /url?q= su host Google standard e ccTLD
• Abuso del percorso AMP (/amp/ senza /s/)
• Reindirizzamenti Web Light dismessi ma ancora raggiungibili su googleweblight.com
• Token di reindirizzamento relativi ai viaggi su /travel/clk
• Reindirizzamenti a catena su Hangouts e App Engine
• Manipolazione degli adurl di DoubleClick e Google Ad Services
• Codifica del nome host su *.translate.goog
• Richieste di autorizzazione OAuth con valori redirect_uri sospetti o non registrati

Il team di ricerca sulle minacce continua a monitorare nuove varianti di formattazione, rotazioni di host e combinazioni con infrastrutture di raccolta delle credenziali e distribuzione di malware.

Raccomandazioni

Formazione sulla consapevolezza degli utenti

• Spiegare ai dipendenti che un link che mostra google.com non garantisce la sicurezza; gli autori degli attacchi abusano regolarmente dei reindirizzamenti di Google per raggiungere pagine dannose
• Istruire gli utenti a controllare la barra degli indirizzi del browser dopo ogni reindirizzamento, specialmente prima di inserire le credenziali
• Avvertire che le pagine di avviso interstiziali di Google possono essere soppresse da determinate combinazioni di parametri; l’assenza di un avviso non indica legittimità
• Sottolineare che non ci si deve fidare delle e-mail non richieste basandosi esclusivamente sul dominio visibile del link

Conclusione

L’abuso dei reindirizzamenti di Google rimane una delle tecniche più durature nel repertorio degli autori delle minacce. Indirizzando le vittime attraverso l’autentica infrastruttura di Google, gli autori degli attacchi ereditano la fiducia nel dominio, aggirano le liste di autorizzazione ingenue e aumentano i tassi di clic nelle campagne di phishing e spam. L’ampiezza delle famiglie di reindirizzamenti — dagli endpoint Web Light ormai dismessi alla manipolazione dei parametri OAuth — implica che i difensori non possano fare affidamento su una singola regola di rilevamento o su un unico elenco di domini consentiti.

Le organizzazioni dovrebbero considerare tutti gli URL di Google presenti nelle e-mail non richieste come non attendibili fino a quando non siano state convalidate l’intera catena di reindirizzamenti e la destinazione finale. I team di sicurezza dovrebbero dare priorità al rilevamento sia nella fase del link contenuto nell’e-mail sia nella fase di reindirizzamento post-clic, prestando particolare attenzione ai reindirizzamenti a catena, all’evasione basata su frammenti e all’abuso di ccTLD e sottodomini di servizio meno monitorati.