Une campagne de phishing se dissimule derrière des redirections Google en cascade pour dérober des identifiants

Les services Google de confiance composent une chaîne d’attaque à trois redirections

Une campagne de phishing actuellement en cours redirige ses victimes vers plusieurs services Google légitimes avant de les conduire vers des pages conçues pour dérober leurs identifiants ou vers des logiciels d’accès à distance.

Les chercheurs de KnowBe4 Prabhakaran Ravichandhiran et Jeewan Singh Jalal ont décrit cette activité le 4 septembre. L’opération s’appuie sur une chaîne de redirections en trois étapes destinée à contourner les passerelles de sécurité des e-mails, les analyseurs d’URL et les systèmes d’inspection automatisés.

Plutôt que d’insérer directement une adresse contrôlée par l’attaquant dans un e-mail malveillant, les opérateurs intègrent notamment Google Meet, l’infrastructure publicitaire DoubleClick, Google Custom Search, Google Image Search, Google Tag Manager et Google Analytics.

Chaque redirection expose les produits de sécurité à un autre domaine réputé exploité par Google. Une passerelle qui accorde une importance élevée à la réputation du domaine peut donc considérer le lien comme légitime, en particulier si elle ne suit pas l’intégralité de la chaîne ou n’analyse pas la page finale dans un véritable navigateur.

Cette technique est plus élaborée qu’un simple raccourcissement ou masquage d’URL malveillante. L’infrastructure est conçue pour rester crédible à chaque étape successive de l’inspection, tandis que la destination peut retarder ou modifier son comportement jusqu’à la fin des contrôles automatisés.

Google n’avait pas commenté la campagne signalée au moment de la publication.

Les fragments d’URL dissimulent les données de ciblage propres à chaque victime

L’un des signaux de détection les plus évidents de cette opération réside dans la présence de l’adresse e-mail du destinataire dans le fragment d’URL, c’est-à-dire la partie située après le caractère #. L’adresse est encodée en Base64 et sert à personnaliser la destination.

Une structure simplifiée pourrait se présenter ainsi :

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

Le fragment possède une propriété intéressante pour les attaquants : en règle générale, les navigateurs ne l’incluent pas dans la requête HTTP envoyée au serveur web. Il reste accessible au JavaScript exécuté côté client, mais peut être absent des journaux d’accès du serveur et des outils de sécurité qui n’enregistrent que la ressource demandée.

Une fois la page finale chargée, son JavaScript peut lire le fragment, décoder l’adresse e-mail et générer une expérience de phishing personnalisée. La page peut préremplir l’identité de la victime et afficher une image du véritable site web de l’organisation derrière une fausse interface de connexion.

Cette méthode procure deux avantages. D’une part, la victime voit une page qui semble liée à son employeur plutôt qu’une demande d’identifiants générique. D’autre part, certaines données de télémétrie réseau et côté serveur peuvent enregistrer la destination de la redirection sans conserver l’adresse e-mail ciblée.

Base64 est un encodage, pas un chiffrement. Un produit de sécurité qui capture l’URL complète peut facilement la décoder. La question est donc de savoir s’il conserve et analyse effectivement le fragment.

La présence d’une adresse e-mail encodée après #, en particulier dans un message redirigeant vers l’infrastructure Google, doit par conséquent être considérée comme un indice de détection particulièrement précieux. Elle ne prouve pas que toutes les URL de ce type sont malveillantes, mais fournit aux défenseurs un motif précis à examiner.

La destination s’adapte à la victime et à l’environnement d’inspection

Les e-mails malveillants s’appuient sur plusieurs prétextes professionnels plutôt que sur un modèle unique et cohérent. Les thèmes observés incluent la relecture de documents, l’expiration d’identifiants, la livraison de colis, les paiements, les prestations sociales et les notifications de messages vocaux.

Après le clic du destinataire, les redirections aboutissent finalement à l’un de deux scénarios principaux. Le premier est une fausse page d’authentification d’entreprise conçue pour recueillir les noms d’utilisateur et les mots de passe. Le second est un processus frauduleux de vérification d’identité qui tente d’installer ScreenConnect.

ScreenConnect est utilisé ici comme outil d’accès à distance, et non comme mécanisme de redirection sous-jacent. Les versions précises de ScreenConnect concernées n’ont pas été divulguées, et la campagne n’est pas présentée comme exploitant une vulnérabilité logicielle. Le danger vient de la capacité à convaincre un utilisateur d’installer ou d’exécuter un logiciel d’administration à distance non autorisé.

Le framework de phishing peut adapter son contenu à la localisation géographique de la victime et prendre en charge plusieurs langues. Il recueille également des informations contextuelles susceptibles d’aider les opérateurs à évaluer la cible et la session compromise.

Les données potentiellement exposées comprennent :

• Les identifiants de connexion professionnels
• Les adresses IP publiques
• Les informations de géolocalisation
• Les chaînes user-agent des navigateurs
• Les enregistrements MX vérifiés associés à l’organisation de la victime
• Les métadonnées de ciblage organisationnel et de session

Les identifiants dérobés et les métadonnées collectées sont transmis aux opérateurs par l’intermédiaire d’un canal Telegram, apparemment en quelques secondes. Telegram constitue une couche de communication pratique, susceptible de se fondre dans d’autres flux de messagerie chiffrés si les défenseurs ne surveillent pas spécifiquement l’activité des bots et des API.

La campagne combine donc personnalisation, évasion et exfiltration rapide. Une interaction réussie peut conduire à la prise de contrôle d’un compte, tandis que l’installation non autorisée de ScreenConnect peut permettre un accès direct à distance.

Pourquoi la réputation du domaine ne suffit pas face à cette technique

De nombreux dispositifs de sécurité des e-mails et du web inspectent le nom d’hôte visible d’un lien, interrogent des services de réputation et suivent un nombre limité de redirections. Ce modèle devient moins efficace lorsque les attaquants peuvent assembler une chaîne à partir de composants légitimes de services cloud et publicitaires.

Bloquer globalement les domaines Google provoquerait d’importantes perturbations opérationnelles. Les attaquants tirent parti de cette contrainte : les défenseurs doivent distinguer les usages malveillants d’un important volume de trafic professionnel ordinaire, plutôt que bloquer purement et simplement l’infrastructure.

Un analyseur peut également observer un comportement différent de celui présenté à un visiteur humain. Le dispositif de collecte final peut attendre la fin de l’inspection, évaluer des signaux environnementaux ou modifier sa réponse selon la localisation et les caractéristiques de la session. Un résultat inoffensif obtenu lors d’une requête automatisée ne garantit donc pas qu’un utilisateur recevra la même page.

Les dispositifs de sécurité doivent par conséquent évaluer l’intégralité du parcours de navigation, notamment :

1. L’URL d’origine intégrée à l’e-mail
2. Chaque redirection intermédiaire et ses paramètres
3. Le domaine enregistré final et son emplacement d’hébergement
4. Les scripts côté client exécutés après le chargement de la page
5. Les fragments d’URL conservés dans le message d’origine
6. Les téléchargements ultérieurs, formulaires de connexion ou demandes d’accès à distance
7. Les communications sortantes initiées après l’interaction de l’utilisateur

Cette campagne ne repose ni sur la compromission d’un produit Google particulier ni sur l’exploitation d’une version vulnérable divulguée. Elle exploite les relations de confiance entre plusieurs services ainsi que les failles de corrélation entre la télémétrie des e-mails, des proxys, des navigateurs, des terminaux et des systèmes d’identité.

Les défenseurs doivent rechercher le trafic Telegram et l’activité de ScreenConnect

Les organisations doivent appliquer les indicateurs de compromission publiés aux systèmes de filtrage DNS, aux passerelles web sécurisées, aux proxys, aux terminaux et aux plateformes SIEM. Un blocage limité à une seule couche risque de laisser passer les étapes ultérieures de la chaîne de redirections.

Les équipes de sécurité doivent également rechercher les connexions sortantes vers l’API Bot de Telegram et les autres communications inhabituelles liées à Telegram. Ce trafic mérite un examen approfondi lorsqu’il suit le clic sur un e-mail suspect, la consultation d’une page d’authentification inconnue ou l’exécution d’un nouveau processus.

La recherche sur les terminaux doit se concentrer sur les installations et activités ScreenConnect non autorisées. Les vérifications pertinentes incluent les événements d’installation inattendus, la création de nouveaux services, les exécutions depuis des répertoires accessibles en écriture par l’utilisateur et les sessions d’accès à distance qui ne correspondent pas à un processus d’assistance approuvé. Les déploiements légitimes de l’organisation doivent être distingués des instances non autorisées.

Les utilisateurs potentiellement concernés doivent réinitialiser leurs mots de passe. Les défenseurs doivent également examiner les journaux d’authentification à la recherche de localisations ou d’appareils inhabituels, de créations de session, de modifications de l’authentification multifacteur et d’accès survenus peu après la réception du message de phishing.

Les mesures défensives utiles incluent :

• Conserver les URL complètes, y compris le contenu situé après le caractère #, dans les données de télémétrie liées à l’analyse des e-mails.
• Décoder les fragments Base64 lors de l’inspection des messages et des URL.
• Suivre toutes les redirections au lieu d’évaluer uniquement le premier nom d’hôte Google.
• Corréler les redirections passant par des services Google avec l’apparition de nouveaux formulaires de connexion.
• Rechercher les téléchargements, installations ou exécutions ultérieurs de ScreenConnect.
• Surveiller le trafic vers l’API Bot de Telegram comme éventuel canal d’exfiltration.
• Rappeler aux utilisateurs que la présence d’un domaine cloud familier ne garantit pas la sécurité de la destination.
• Examiner les messages évoquant des documents, des livraisons, des paiements, des messages vocaux, des prestations sociales ou l’expiration d’identifiants.

La sensibilisation des utilisateurs doit porter sur les comportements plutôt que sur les marques. Un lien peut commencer sur un service Google légitime et aboutir malgré tout à une page contrôlée par un attaquant. Les demandes d’authentification inattendues et les vérifications d’identité nécessitant un logiciel d’accès à distance doivent être signalées plutôt que suivies.

La caractéristique déterminante de cette campagne n’est pas un appât de phishing particulier. C’est l’utilisation coordonnée d’une infrastructure de redirection de confiance, de données de ciblage dissimulées, d’un contenu web adaptatif et d’une exfiltration quasi instantanée pour donner à une attaque personnalisée une apparence ordinaire.