Les limites de la réécriture d’URL et du scan de liens
La réécriture d'URL au moment du clic est l'une des fonctions de sécurité e-mail les plus appréciées : chaque lien est remplacé par une URL détenue par la passerelle, afin de revérifier la destination à l'instant où l'utilisateur clique. Elle attrape une grande part du phishing et mérite d'être en place. Mais ce n'est pas le filet de sécurité que beaucoup d'équipes imaginent, et connaître ses angles morts maintient les attentes — et les défenses — honnêtes.
Comment fonctionnent la réécriture et le scan de liens
À l'arrivée du courrier, la passerelle réécrit les liens pour les faire transiter par son propre service d'analyse :
Original : https://example.com/doc
Réécrit : https://urldefense.example/v3/__https://example.com/doc__;!!TOKEN
Au clic, l'utilisateur atteint d'abord la passerelle, qui évalue la destination — réputation, détonation en bac à sable, analyse de contenu — puis autorise, avertit ou bloque. Le principe est sain : vérifier le lien au moment qui compte, pas seulement à la livraison. Le problème est qu'un attaquant déterminé contrôle précisément ce qui est vérifié.
Pourquoi c'est imparfait
Le scanner est un visiteur connu et distinguable
La réécriture ne fonctionne que si la passerelle suit le lien, et ce fetch diffère du navigateur d'une vraie victime. Les attaquants détectent le scanner et lui servent quelque chose de propre.
- Camouflage (cloaking). Le serveur inspecte user-agent, ASN et schémas de requête, et montre une page anodine aux visiteurs automatisés tout en montrant la page de phishing aux victimes.
- Géofiltrage. La page ne s'active que pour les plages IP correspondant au pays ou à l'organisation cible ; les IP du scanner cloud reçoivent une réponse anodine.
- CAPTCHA et portails d'interaction. Un CAPTCHA, un « cliquez pour continuer » ou un cookie requis arrête un crawler automatisé avant même la charge — mais un humain passe sans encombre.
Scanner passerelle → CAPTCHA / page anodine → verdict : propre
Victime humaine → franchit le portail → page d'identifiants active
Le lien change après avoir été jugé
Même un scan parfait n'est qu'un instantané.
- Armement différé. L'URL pointe vers une page anodine au moment du scan, puis bascule ensuite vers la charge de phishing. Le verdict est déjà en cache.
- Liens à usage unique. Un jeton dans l'URL se consume après une visite. Si le scanner le dépense, la page affiche un 404 inoffensif — et la victime, arrivant avec un jeton frais, obtient la page active. Si la victime le dépense d'abord, un enquêteur ultérieur ne voit que le 404.
Les chaînes de redirection blanchissent la destination
Le lien réécrit peut pointer vers un domaine réputé qui se contente de rediriger : une redirection ouverte, un raccourcisseur d'URL, un tracker marketing légitime, ou une suite de sauts finissant sur une infrastructure fraîchement enregistrée. Les scanners ne suivent qu'un nombre limité de sauts, et la destination finale peut être remplacée ou verrouillée indépendamment de la première.
L'hébergement de confiance résiste au blocage
Quand la destination est SharePoint, Google Drive ou un domaine derrière Cloudflare, un verdict propre est souvent correct sur le moment — le fichier ou la page y est bien hébergé — alors que le contenu est l'appât. Le scanner ne peut bloquer la plateforme en bloc.
La réécriture vérifie un lien selon les conditions de l'attaquant. Qui contrôle la destination contrôle ce que voit le scanner, et peut le changer après le verdict.
La défense en profondeur
La réécriture d'URL devrait être une couche parmi plusieurs, précieuse mais jamais porteuse à elle seule :
- MFA résistante au phishing (FIDO2/passkeys) pour qu'un lien atteignant même une page d'identifiants active ne produise aucune connexion exploitable.
- Protections endpoint et navigateur évaluant la page telle que rendue, après toutes les redirections et portails.
- Surveillance des domaines récents et de la transparence des certificats pour raccourcir le temps de réaction sur les infrastructures sosies.
- Une couche humaine formée et signalante — le contrôle qui juge la page réellement livrée, là précisément où le scan automatisé a été trompé.
L'objectif n'est pas de se méfier de la réécriture, mais de cesser de traiter un verdict au clic comme une preuve de sécurité. C'est une entrée probabiliste parmi d'autres, et les attaques conçues pour la franchir sont celles que vos autres couches existent pour attraper.
Comment GottaPhish aide
La réécriture d'URL au moment du clic attrape beaucoup de choses, mais ce n'est pas le filet de sécurité que beaucoup d'équipes imaginent : camouflage, pages à portail, liens à usage unique et chaînes de redirection trompent régulièrement le scan automatisé, si bien que la couche de scan de liens laisse toujours des angles morts à elle seule. GottaPhish et son équipe d'experts vous montrent ce que la réécriture d'URL arrête vraiment — et ce qu'elle manque — via des simulations autorisées et intégralement auditées reproduisant ces techniques en toute sécurité, avec des données par utilisateur et par service sur qui atteint la page et qui la signale. Nos experts vous aident à concevoir les scénarios, déployer les campagnes et interpréter les tableaux de bord, afin que cette preuve affine vos priorités de défense en profondeur. Résultat : vos équipes deviennent une dernière ligne de détection fiable là où le scan automatisé peut être trompé.