L'utilisation abusive des redirections Google favorise le phishing et l'envoi de spam

5 août 2026

Présentation de la menace

L'abus de redirection Google est une technique très répandue dans laquelle les cybercriminels exploitent les services légitimes de redirection d'URL de Google pour masquer des liens malveillants, contourner les systèmes de sécurité des e-mails et renforcer la légitimité apparente des campagnes de hameçonnage et de spam. Les attaquants tirent parti de la réputation de confiance des domaines Google afin que les liens semblent pointer vers google.com (ou d’autres sites Google) tout en redirigeant les utilisateurs vers des pages visant à voler leurs identifiants, des logiciels malveillants ou du contenu indésirable.

Comme ces redirections proviennent de l’infrastructure authentique de Google, elles passent souvent avec succès les contrôles de réputation de domaine, les politiques de réécriture d’URL et l’examen minutieux des utilisateurs. Les défenseurs qui s’appuient sur une liste blanche incluant *.google.com ou qui considèrent les URL Google comme intrinsèquement sûres restent exposés à ce type d’abus.

 Le service de recherche sur les menaces de Mimecast continue d’observer des techniques de redirection Google dans le cadre de la collecte d’identifiants et du spam à haut volume. Les sections ci-dessous présentent les principales familles de redirections, leur structure d’URL et leur comportement de contournement.

 Familles de redirections

1. Google Web Light

Google Web Light était un service de transcodage qui proposait des versions allégées et plus rapides des pages web aux utilisateurs disposant de connexions mobiles lentes (par exemple en 2G), principalement dans des pays tels que l’Inde, le Brésil et l’Indonésie. Il utilisait le domaine googleweblight.com et les ressources de niveau chemin « sp » et « i » pour récupérer et rediriger vers une URL cible transmise via le paramètre « u ».

Google a mis fin à Web Light le 19 décembre 2022 et a supprimé la documentation publique, mais le domaine et le comportement de redirection restent accessibles et continuent d’être utilisés à des fins malveillantes dans le cadre de campagnes malveillantes.

Exemple d’URL

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

2. Redirection d'URL principale : `google.*/url`

Le mécanisme principal est la redirection ouverte vers des chemins tels que /url sur divers hôtes Google.

Recherchez « google./url? » avec un paramètre « q= » contenant une URL. Tout hébergeur proposant ce chemin d'accès peut rediriger vers une destination arbitraire.

Exemple d’URL

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

Paramètres habituels

3. Abus liés à Google AMP (Accelerated Mobile Pages)

Google AMP est un framework HTML open source utilisé pour créer des sites web optimisés pour les navigateurs et les appareils mobiles. Comme AMP permet d’afficher le contenu des pages web en ligne, les cybercriminels en abusent désormais pour présenter des pages de hameçonnage en temps réel dès que l’utilisateur clique sur un lien.

Abus AMP autonome

AMP valide :

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

Forme abusive (omission du « s ») :

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

Cette variante est relativement rare dans le trafic légitime, mais apparaît dans de nombreuses campagnes malveillantes. Elle est souvent associée à d’autres indicateurs de phishing plutôt que d’être utilisée comme seul critère de blocage.

Les attaquants intègrent des URL Google AMP dans leurs e-mails (par exemple ...&url=amp/malicious-site.com). Lorsque le paramètre « q » est modifié, la destination finale peut être altérée tout en passant par Google, de sorte que le lien visible reste une URL Google.

Exemple de modèle

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

La modification du dernier chemin dans url=amp/... peut rediriger vers un site arbitraire ; la suppression de /amp déclenche souvent la page d’avertissement interstitielle de Google.

Ce service est très tolérant en matière de formatage des URL et normalise un large éventail de formatages incorrects, ce qui permet aux acteurs malveillants de contourner les mesures de visibilité existantes en modifiant les URL de manière inattendue.

4. Google Travel : `/travel/clk`

Cette redirection ouverte est liée au service Google Travel, disponible sur tous les noms de domaine Google. Elle redirige le trafic vers des sites externes via le produit Google Travel. Il s’agit d’une redirection ouverte partiellement contenue : un jeton généré par le système est requis, mais celui-ci ne restreint pas la destination vers laquelle la redirection peut pointer. Ce jeton peut être généré via Google Travel sur demande et n’empêche pas la modification de la destination.

Exemple d'URL

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

5. Hôtes Google non standard (ccTLD et sous-domaines de service)

Même structure que la redirection d'URL principale ; seul le nom d'hôte change.

Les attaquants utilisent le même modèle /url?q= (ou équivalent) sur des hôtes autres que www.google.com, par exemple google.es, google.de, google.fr, maps.google.*, contacts.google.* et drive.google.*. Il s'agit de propriétés Google légitimes, mais elles sont moins souvent incluses dans les règles spécifiques aux redirections.

Domaines nationaux (ccTLD)

Les attaquants utilisent des ccTLD Google moins surveillés afin que les listes d’autorisation basées sur les domaines et les vérifications de réputation continuent de détecter « Google », tout en réduisant la portée des règles personnalisées.

Exemples :

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

Sous-domaines de services

Les abus de redirection sont également observés sur des sous-domaines qui ne sont généralement pas associés à des redirections de liens, ce qui augmente le nombre de cas de figure que les défenseurs doivent gérer :

Ces liens apparaissent également dans le cadre de chaînes de redirection provenant d’autres sites :

URL d'origine → redirection Google (avec &sa=D&sntz=1&usg=) → valeur url?q=

6. Google Meet/Hangouts et App Engine

(1) Meet

Chemin d’meet.google.com/linkredirect avec le paramètre de requête dest= contenant l’URL de destination. Auparavant, Google Hangouts suivait également un chemin similaire pour la redirection.
https://meet.google.com/linkredirect?dest=https://malicious-site.com

(2) App Engine

Chemin appengine.google.com/_ah/logout avec continue= pointant vers une autre URL (souvent Hangouts ou le site final). Dans les e-mails, les chaînes combinant les deux constituent un signal d’abus fort.

Exemple de redirection en chaîne

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/...

De telles chaînes (déconnexion d’App Engine → Hangouts → destination finale) n’ont aucune utilisation légitime courante dans les e-mails et justifient un blocage à haut niveau de confiance.

7. Google DoubleClick / Services publicitaires

Les produits d’analyse des liens marketing de Google exposent des redirections ouvertes sur googleadservices.com et doubleclick.net. Contrairement aux redirections /url de Google Search, celles-ci ne sont pas officiellement documentées comme étant protégées contre les abus et font l’objet d’une utilisation abusive croissante. Les attaquants récupèrent généralement des liens publicitaires valides et ne modifient que la destination « adurl », en enchaînant souvent d’autres redirections et en conservant les fragments de requête (par exemple, l’adresse e-mail du destinataire) afin de personnaliser leurs pages de hameçonnage.

(1)doubleclick.net

Exemple d’URL

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

(2) googleadservices.com

Exemple d'URL

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

8. Google Translate

translate.goog fait l'objet d'abus par l'encodage du domaine de phishing dans le nom d'hôte.

Exemple d'URL

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

(Se décode en hôte de destination phishing.com.)

Les noms d'hôte prennent la forme *..translate.goog, où le sous-domaine correspond au domaine cible, les points étant remplacés par des tirets (par exemple, example.com → example-com.translate.goog). Des paramètres tels que _x_tr_sl=auto et _x_tr_tl=en peuvent être présents. Les filtres de sécurité sont moins susceptibles de les signaler, car ils apparaissent comme des domaines Google légitimes.

Modèle de construction

1. Remplacer les points du domaine cible par des tirets (par exemple example.com → example-com)
2. Utiliser comme sous-domaine de translate.goog : https://example-com.translate.goog
3. Des paramètres facultatifs tels que _x_tr_sl=auto, _x_tr_tl=en donnent à l’URL l’apparence d’un lien Translate normal

9. Redirection OAuth de Google

Google OAuth 2.0 est un cadre d'autorisation conforme aux normes de l'industrie, conçu pour permettre un accès sécurisé et délégué aux comptes des utilisateurs sans nécessiter le partage de mot de passe. Le système permet à des applications tierces de demander des autorisations limitées et bien définies pour accéder aux données des utilisateurs (e-mail, profil, agenda, etc.) via un processus de consentement contrôlé par l'utilisateur.

Les flux d’autorisation Google OAuth 2.0 utilisent une redirection pour renvoyer l’utilisateur vers l’application après son consentement. Le paramètre `redirect_uri` indique à Google où rediriger l’utilisateur (ainsi que le code d’autorisation ou le jeton). Si un attaquant parvient à contrôler ou à influencer cette valeur, il peut voler des codes d’autorisation ou des jetons, ou rediriger les utilisateurs vers une page de hameçonnage après une connexion Google d’apparence légitime.

Exemple d’URL (demande d’autorisation)

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

Techniques de contournement

Le jeton usg étant lié à la chaîne de requête, les attaquants ne peuvent pas modifier librement les paramètres de requête pour transmettre des données spécifiques à l’utilisateur sans invalider la redirection. Ils utilisent donc des fragments d’URL pour le suivi, le pré-remplissage de formulaires ou la transmission de jetons à la page finale sans interrompre la redirection Google.

Les fragments d’URL (la partie après le signe #) :

• Ne sont pas envoyés au serveur
• Ne sont pas pris en compte dans la validation usg
• Sont conservés par le navigateur lors de la redirection

Exemple

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

Autres techniques de contournement :

Protection Mimecast

Mimecast a identifié des attributs associés aux abus de redirection Google grâce à l’analyse des liens dans les e-mails, à l’inspection de la réécriture d’URL et à l’évaluation des chaînes de redirection post-clic. La couverture de détection s’étend aux :

• Les redirections « /url?q= » sur les hôtes Google standard et ccTLD
• les abus de chemins AMP (/amp/ sans /s/)
• Les redirections Web Light obsolètes mais toujours accessibles sur googleweblight.com
• les jetons de redirection « Travel » sur /travel/clk
• les redirections en chaîne de Hangouts et d’App Engine
• Manipulation des URL publicitaires DoubleClick et Google Ad Services
• Codage des noms d'hôte sur *.translate.goog
• Demandes d’autorisation OAuth avec des valeurs redirect_uri suspectes ou non enregistrées

L'équipe de recherche sur les menaces continue de surveiller l'apparition de nouvelles variantes de formatage, les rotations d'hôtes et les combinaisons avec des infrastructures de collecte d'identifiants et de diffusion de logiciels malveillants.

Recommandations

Formation à la sensibilisation des utilisateurs

• Expliquez aux employés qu’un lien affichant google.com ne garantit pas la sécurité ; les attaquants exploitent régulièrement les redirections Google pour accéder à des pages malveillantes
• Demandez aux utilisateurs de vérifier l’adresse finale dans la barre d’adresse du navigateur après toute redirection, en particulier avant de saisir leurs identifiants
• Prévenez-les que les pages d’avertissement interstitielles de Google peuvent être masquées par certaines combinaisons de paramètres ; l’absence d’avertissement n’est pas un gage de légitimité
• Insistez sur le fait qu’il ne faut pas se fier aux e-mails non sollicités en se basant uniquement sur le domaine visible du lien

Conclusion

L’exploitation abusive des redirections Google reste l’une des techniques les plus persistantes dans l’arsenal des acteurs malveillants. En acheminant les victimes via l’infrastructure authentique de Google, les attaquants héritent de la confiance accordée au domaine, contournent les listes d’autorisation naïves et augmentent les taux de clics sur les campagnes de hameçonnage et de spam. La diversité des familles de redirections — des points de terminaison Web Light désaffectés à la manipulation des paramètres OAuth — signifie que les défenseurs ne peuvent pas se fier à une seule règle de détection ou à une seule liste blanche de domaines.

Les organisations doivent considérer toutes les URL Google présentes dans les e-mails non sollicités comme non fiables jusqu’à ce que la chaîne de redirection complète et la destination finale aient été validées. Les équipes de sécurité doivent donner la priorité à la détection tant au stade du lien dans l’e-mail qu’à celui de la redirection post-clic, en accordant une attention particulière aux redirections en chaîne, aux techniques d’évasion basées sur les fragments et à l’utilisation abusive des ccTLD et des sous-domaines de services moins surveillés.