URL suspecte : vérifier les redirections sans cliquer

Pour examiner une URL suspecte sans la visiter, copiez sa cible en texte, repérez les données sensibles et consultez les observations existantes. Si elles ne permettent pas de connaître les redirections, confiez l’ouverture à un environnement d’analyse isolé. Lire une URL ne révèle pas nécessairement la réponse que son serveur enverra.

Cette distinction compte lors d’un signalement de phishing : « sans cliquer sur mon poste » reste compatible avec une analyse distante qui contacte le site. Le contact existe alors bien, depuis l’environnement d’analyse, et doit être décidé en connaissance de cause.

Extraire le lien sans déclencher une prévisualisation

Conservez le message d’origine et sa date. Dans une messagerie, utilisez la copie de l’adresse du lien ou l’export du message selon votre procédure. Le texte visible « Voir ma facture » peut différer de la cible réelle.

Collez l’adresse dans un éditeur de texte local qui ne charge pas d’aperçu. Évitez la barre d’adresse du navigateur et les conversations qui développent automatiquement les liens. Sur mobile, un appui prolongé peut afficher un aperçu selon l’application ; l’export ou le signalement intégré est préférable si vous ne maîtrisez pas ce comportement.

Gardez l’original dans le dossier d’incident à accès restreint. Pour communiquer l’indicateur, utilisez une forme neutralisée telle que hxxps://connexion[.]example/login. Cette notation limite les clics accidentels, mais ne chiffre ni ne masque les données qu’elle contient.

Lire l’URL complète avant de réduire au domaine

Séparez le schéma, le nom d’hôte, le chemin et les paramètres. Repérez les champs qui semblent contenir une autre adresse, sans supposer qu’ils décrivent la destination effective.

Exemple fictif, volontairement neutralisé :

hxxps://liens[.]example/r?dest=https%3A%2F%2Fconnexion.example%2Flogin&recipient=[masqué]

Le paramètre dest contient une adresse encodée. La décoder localement permet de lire une destination déclarée. Cela ne prouve pas que le serveur y redirigera : il peut ignorer le paramètre, vérifier un jeton ou répondre autrement. Conservez la valeur originale à côté de la version lisible ; des transformations successives peuvent modifier le sens de la requête.

La présence d’un nom de marque dans le chemin ou un paramètre ne prouve pas que la marque contrôle l’hôte. Comparez le domaine avec celui obtenu depuis un canal indépendant : application connue, favori établi ou interlocuteur déjà identifié. Le message suspect ne doit pas fournir lui-même toute la preuve de son authenticité.

• URL complète : quel chemin et quels paramètres le message cherche-t-il à ouvrir ?
• Domaine ou nom d’hôte : quelle destination nommée est impliquée ?
• IP d’hébergement observée : quelle infrastructure servait cette destination au moment relevé ?

Un classement du domaine ne décrit pas forcément chaque chemin. De même, la réputation d’une IP partagée ne suffit pas à qualifier tous ses sites. Utilisez la vérification de domaine pour ajouter du contexte, en gardant l’URL complète comme pièce de l’investigation.

Chercher une observation existante

Avant de soumettre une nouvelle analyse, cherchez si le lien ou son domaine apparaît déjà dans des résultats. La recherche urlscan donne accès à des scans archivés et permet de filtrer par date. Documentation de recherche urlscan.

Comparez l’URL initiale du scan à celle du signalement. Un résultat sur le même domaine avec un autre chemin n’observe pas nécessairement la même page. Relevez l’heure, l’adresse de départ, les changements de domaine et la destination observée. Consultez les détails enregistrés, sans suivre les liens sortants vers le site suspect.

Une recherche dans des archives ne déclenche pas, à elle seule, une nouvelle visite de la cible. Elle transmet toutefois votre requête au fournisseur : n’y collez pas un jeton confidentiel pour obtenir une correspondance exacte. Commencez par un domaine public ou un chemin non sensible.

Scénario fictif : un lien de courriel passe par une redirection avant une page de connexion. Chaque étape doit être identifiée ; la présence d’une redirection ne constitue pas une preuve de phishing.

Vérifier la confidentialité avant tout nouveau scan

Une URL peut contenir une adresse de destinataire, un identifiant de document, un lien de réinitialisation ou un jeton de connexion. Soumettre cette URL à un service transmet ces valeurs à ce service. Selon le lien, sa consultation peut aussi consommer un accès unique ou confirmer une interaction.

Chez urlscan, les résultats publics sont visibles publiquement ; les scans unlisted restent accessibles à certains chercheurs et clients professionnels. Le mode private limite l’accès au compte et aux personnes recevant l’identifiant du scan. Niveaux de visibilité urlscan.

Vérifiez donc le mode effectif et les règles de votre organisation avant l’envoi. Pour un secret utilisable, privilégiez l’environnement interne autorisé. Retirer les paramètres protège certaines données, mais produit une autre URL : le résultat ne valide alors pas le lien original. Documentez cette limite plutôt que de présenter le scan comme équivalent.

Observer les redirections dans un environnement isolé

Si une nouvelle observation est nécessaire et autorisée, utilisez un environnement dédié sans session personnelle ou professionnelle, avec un accès réseau encadré. Ne connectez aucun compte et ne fournissez aucun identifiant à la page pour « aller plus loin ».

Une redirection HTTP peut apparaître sous forme de réponse 302 et d’en-tête Location. Les changements de page peuvent aussi provenir de HTML ou de JavaScript. Une simple lecture d’en-têtes ne couvre donc pas tous les mécanismes. Guide MDN sur les redirections.

Un outil qui développe un lien réalise lui aussi une requête : l’absence de fenêtre de navigateur ne rend pas cette opération passive. Notez chaque étape observée, les erreurs et le point où l’analyse s’arrête. N’affirmez pas avoir obtenu une chaîne complète lorsque le parcours exige une interaction absente du scan.

La configuration fait partie de la preuve. L’API urlscan permet notamment de choisir un agent utilisateur et un pays de scan ; conservez ces paramètres lorsqu’ils sont connus. Options de l’API urlscan. Le résultat décrit une observation dans ces conditions, sans garantir ce que verra un autre appareil.

Rendre un verdict sur le lien réellement observé

Le compte rendu doit relier le message, l’URL d’origine, les destinations observées, leurs horaires et les éléments qui justifient la décision. Distinguez une destination confirmée malveillante, un parcours suspect encore incomplet et une vérification qui n’a rien trouvé.

Si le contenu attendu existe, consultez-le depuis le service officiel ouvert indépendamment du message. Pour poursuivre le triage d’un lien non confidentiel, le scanner d’URL IsMalicious fournit un point d’entrée ; gardez les observations et leurs limites dans le dossier. Notre guide des URL et de leurs menaces cachées complète cette procédure avec les signes courants de tromperie.