Depuis mi‑juin 2024, les cybercriminels exploitent une fonctionnalité conçue pour protéger les utilisateurs : le rewriting d’URL mis en place par de nombreux fournisseurs de sécurité e‑mail. En transformant des liens dans les messages pour les faire passer par des serveurs de filtrage, ces services visent à empêcher la diffusion de sites malveillants. Les attaquants ont cependant appris à tirer parti de ce mécanisme pour camoufler des URLs malveillantes derrière des liens « réécrits » et ainsi tromper la vigilance des utilisateurs et des équipes de sécurité.

Comment fonctionne le rewriting d’URL ?

Principe : les liens contenus dans un e‑mail sont remplacés par une URL intermédiaire pointant vers l’infrastructure du fournisseur de sécurité. Le lien est analysé (scanning) et, si jugé sûr, redirige vers la destination finale.

Approches existantes  :

• Solutions legacy : basées sur règles, signatures et listes noires historiques
• Solutions modernes : recours au machine learning et à la computer vision pour analyser les pages en temps réel.

Effet secondaire : certaines organisations utilisent une combinaison des deux approches, générant parfois un  “double  rewrite” (réécriture multiple) d’un même lien.

La technique d’exploitation utilisée par les attaquants : les attaques observées suivent un schéma récurrent et ingénieux !

• Compromission d’un compte légitime protégé par rewriting.

• Envoi depuis ce compte d’un message contenant une URL « propre » (considérée sûre par le service).

• Le service de sécurité réécrit le lien — créant ainsi une URL appartenant à une marque de sécurité reconnue.

• L’attaquant modifie ensuite la destination du lien réécrit pour pointer vers un site de phishing ou de collecte d’identifiants.

• Le résultat : un lien affichant un préfixe connu et réputé sûr qui, en réalité, conduit à une page malveillante. Cette manipulation profite de la confiance des utilisateurs dans les marques de sécurité et réduit la suspicion lors du clic.

Exemples d’attaques et scénarios observés (synthèse des cas signalés)

Double Rewrite (Proofpoint + INKY) : lien réécrit apparaissant comme une notification SharePoint, intégrant un CAPTCHA pour éviter l’analyse automatique.

Exploitation multi‑cible : génération d’un lien réécrit depuis une organisation compromise puis réutilisation pour cibler  d’autres entités.

Abus de services spécifiques : attaques utilisant les services de rewriting de Mimecast, Sophos, etc., pour masquer des  pages de credential‑stealing ou de fraude (ex. phishing IRS impersonation).

Pourquoi cette technique est dangereuse ?

Elle exploite la confiance en des marques de sécurité et la perception erronée « si le lien est réécrit, il est sûr ».

Le rewriting rend la détection plus complexe pour les outils statiques (les liens semblent provenir d’un domaine légitime de sécurité).

L’usage de CAPTCHA et de techniques anti‑sandbox complique l’analyse automatisée.

La compromission d’un compte légitime contourne l’authenticité apparente du message.

Mesures de défense recommandées.

• Ne pas se fier uniquement à la présence d’un préfixe de rewriting : vérifier la destination réelle du lien avant de saisir des identifiants.

• Doubler les contrôles côté serveur :

Analyser le comportement post‑clic (dynamic analysis) et non seulement l’URL statique.

Corriger les processus de gestion des cas de double‑rewrite (logique pour vérifier la chaîne complète de redirections).

• Renforcer la protection des comptes :

Authentification multifacteur obligatoire.

Surveillance des sessions et détections d’anomalies (login depuis nouveaux IP, envois en masse inhabituels).

• Détection et réponse post‑livraison :

Solutions capables d’exécuter le rendu d’une page (browser emulation / computer vision) pour détecter des pages de credential‑stealing.

Analyse comportementale et corrélations d’événements sur les flux e‑mail et web.

• Sensibilisation des utilisateurs :

Former aux signaux d’alerte (URL masquées, demandes d’identifiants, urgences inhabituelles).

Procédures de vérification pour les actions sensibles (procédure out‑of‑band pour confirmer demandes financières ou modifications d’accès).

• Compléments techniques :

Extensions de sécurité au niveau du navigateur pour bloquer les redirections suspectes.

Mise à jour et audit des configurations des solutions de rewriting utilisées : s’assurer des politiques de contrôle des redirections et des journaux complets.

Solutions avancées et recours aux analyses dynamiques Les technologies de Dynamic URL Analysis (rendu complet, anti‑évasion avancée, post‑livraison) représentent aujourd’hui un moyen performant pour contrer ces attaques. Elles permettent d’identifier les pages malveillantes qui utilisent CAPTCHA, géo‑filtrage ou autres techniques d’évasion, et d’intervenir même après la livraison d’un e‑mail.

Le rewriting d’URL, conçu pour protéger les utilisateurs, peut devenir un vecteur d’attaque si les acteurs malveillants parviennent à en manipuler le flux. Pour les PME et les MSP, la réponse implique une approche en couches : protection technique moderne (analyse dynamique, surveillance des comptes), bonnes pratiques opérationnelles et formation des utilisateurs. L’assiette des attaques évolue — l’arsenal défensif doit faire de même.

Vous voulez que votre PME ne soit plus une proie facile ? 

Vous souhaitez tester la résistance de vos flux e‑mail et la configuration de vos solutions de rewriting ? D‑Mute propose des audits, simulations de phishing avancées et vérifications de post‑livraison pour identifier et corriger ces risques.

🔗 Prenez rendez-vous sur https://d-mute.fr/contact/ avant que le prochain email piégé ne vous coûte une fortune.

–